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

[Florian Westphal <fw@strlen.de>]

Paolo Abeni <pabeni@redhat.com> wrote:
> > 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).

We're close to the 8-extensions limit (u8 id), the total blob size can
be 2k, as offset is in '>> 8' units.

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

Yes, there are extensions that are expected to be mutually exclusive,

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

Yes, simple union this, union that, is too fragile, skb_ext_add will
have to check and reject as you say.

OTOH, I think this is orthogonal to what Jakub S. needs for the BPF
extension.