Re: [PATCH RFC net-next] net: Use fixed slots for skb extensions

[Paolo Abeni <pabeni@redhat.com>]

On 8/26/26 11:02 PM, Florian Westphal wrote:
> Jakub Sitnicki <jakub@cloudflare.com> wrote:
>> Replace the dynamic skb extension allocator (->chunks + per-object offset[]
>> array) with fixed per-id slots with offsets computed at compile time.
> 
> Why is that better than
> 
> struct skb_ext {
> 	refcount_t refcnt;
> 	struct secpath s;
> 	struct nf_bridge_info b;
> 	...
> 
> ?

I *think* the layout above would possibly be better (with compiler's
guard around each struct definition).

> Yes, initially this was krealloc()'d area.  But the other assumption
> was that most skbs will carry no extension at all, or, in some configs
> one maybe two (IPsec gateway for instance).
> 
> Thats why the first added extension is also at the beginning of the
> memory blob (that needs to be accessed anyway), regardless of the ID.
> 
> I don't insist on keeping offsets[], if you feel like microbenchmarking
> different use-cases to see if it makes a difference to have a fixed
> memory layout feel free to explore that.

Both options for different skb ext layouts save a few bytes from the
final `struct skb_ext` size. This is IMHO quite relevant as the total
size is approaching the memory partition size (IIRC it's almost 256
bytes), and the bpf ext could make skb_ext require the next one (512).

That in turn should impact performances quite noticeably (IIRC we
observed measurable regression for bulk transfers due to similar changes
in the past), as the number of slabs required to support the same number
of in-flight packets will double, putting more pressure on the memory
allocator and possibly hitting the slab slow-path.

Still WRT optimizing skb_ext size, I think that it should be feasible to
optimize the layout proposed by Florian by taking in account that some
exts are 'mutually exclusive' i.e. on top of my head mptcp and bridge
should never be attached to the same skb, and I *guess* can_skb_ext is
mutually exclusive with most of the others.

The layout could be adapted to such constraints, and there could be
run-time checks (under DEBUG_NET) to verify such constrains at skb_add
time leveraging `present_extensions` and a static matrix describing the
mutual exclusive status for all extensions.

/P