Re: [PATCH net-next 1/3] net: ipv6: ioam6_iptunnel: mitigate 2-realloc issue

[Justin Iurman]

On 10/25/24 17:12, Alexander Lobakin wrote:
> From: Justin Iurman <justin.iurman@xxxxxxxxx>
> Date: Fri, 25 Oct 2024 15:37:25 +0200
>
> > This patch mitigates the two-reallocations issue with ioam6_iptunnel by
> > providing the dst_entry (in the cache) to the first call to
> > skb_cow_head(). As a result, the very first iteration would still
> > trigger two reallocations (i.e., empty cache), while next iterations
> > would only trigger a single reallocation.
>
> [...]
>
> >   static int ioam6_do_inline(struct net *net, struct sk_buff *skb,
> > -			   struct ioam6_lwt_encap *tuninfo)
> > +			   struct ioam6_lwt_encap *tuninfo,
> > +			   struct dst_entry *dst)
> >   {
> >   	struct ipv6hdr *oldhdr, *hdr;
> >   	int hdrlen, err;
> >   
> >   	hdrlen = (tuninfo->eh.hdrlen + 1) << 3;
> >   
> > -	err = skb_cow_head(skb, hdrlen + skb->mac_len);
> > +	err = skb_cow_head(skb, hdrlen + (!dst ? skb->mac_len
> > +					       : LL_RESERVED_SPACE(dst->dev)));
>
> You use this pattern a lot throughout the series. I believe you should
> make a static inline or a macro from it.
>
> static inline u32 some_name(const *dst, const *skb)
> {
> 	return dst ? LL_RESERVED_SPACE(dst->dev) : skb->mac_len;
> }
>
> BTW why do you check for `!dst`, not `dst`? Does changing this affects
> performance?

Not at all, you're right... even the opposite actually. Regarding the 
static inline suggestion, it could be a good idea and may even look like 
this as an optimization:

static inline u32 dev_overhead(struct dst_entry *dst, struct sk_buff *skb)
{
	if (likely(dst))
		return LL_RESERVED_SPACE(dst->dev);

	return skb->mac_len;
}

The question is... where should it go then? A static inline function per 
file (i.e., ioam6_iptunnel.c, seg6_iptunnel.c, and rpl_iptunnel.c)? In 
that case, it would still be repeated 3 times. Or in a header file 
somewhere, to have it defined only once? If so, what location do you 
think would be best?