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

[Jakub Sitnicki <jakub@cloudflare.com>]

On Thu, Aug 27, 2026 at 09:42 AM +02, Paolo Abeni wrote:
> 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.

Right, we could have unions for the mutually exclusive options.

> 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.

Having checks like that that sounds like the right first step that can
be done independently of skb_ext layout changes. I can give that a shot.

Thanks for feedback.