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

On Thu, Aug 27, 2026 at 09:42 AM +02, Paolo Abeni wrote:

On 8/26/26 11:02 PM, Florian Westphal wrote:

quoted

Jakub Sitnicki [off-list ref] wrote:

quoted

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

quoted

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.