Re: [PATCH net-next v2 00/14] skb extension for BPF metadata

["Alexei Starovoitov" <alexei.starovoitov@gmail.com>]

On Fri Sep 11, 2026 at 4:33 AM PDT, Jakub Sitnicki wrote:
> On Thu, Sep 10, 2026 at 08:56 AM -07, Alexei Starovoitov wrote:
>> On Thu Sep 10, 2026 at 7:02 AM PDT, Jakub Sitnicki wrote:
>>>
>>> That said, as things stand we have already established in v1 [3] that for
>>> our existing use case - attaching metadata to <1% of skbs - the
>>
>> so you'll be using this bpf_skb_ext only on <1% of skb-s ?
>> How about we add a bit in skb 'special_cleanup' or something.
>> If set it will trigger a new tracepoint during kfree_skb/consume_skb. 
>> Then use bpf_rhashtable, populate when necessary, set bit,
>> attach to that new tracepoint and delete from rhash where key==skb.
>> bpf_rhash is specifically optimized for 8-byte keys.
>> I suspect it would be faster than this approach.
>>
>> Overall this approach is fine from bpf perspective, but if it can be
>> done with 1 bit + tracepoint approach that would be better.
>
> Thanks for taking a look.
>
> Yes, our existing use case attaches metadata to only <1% of skbs.
> Even if we implemented all other use cases we have in mind, we would
> still only go up to ~5% of skbs by my best estimates.
>
> So the gated-tracepoint, if we can call it that, makes much sense.
> Plus the idea of having a separate RHASH for each user is very
> appealing. No coordination between users needed, just like for BPF local
> storage.
>
> I did some digging what it would take to make the gated-tracepoint idea
> wholesome:
>
> 1. kfree_skb/consume_skb cover only the normal free path. We would also
> need to hook up to GRO merge/recycle and TCP coallesce/collapse. IOW
> everywhere where we call skb_ext_reset/put today.
>
> 2. cloning - we would have to hook up to __copy_skb_header, so where we
> call __skb_ext_copy. Plus some handling of fast clones would be needed -
> perhaps a way to resolve &skb to its fclone twin address?
>
> I think it deserves at least a prototype before we make a call.

code is free. Pls produce patches and benchmark them.

> Code-wise I'm thinking it might be easiest to take advantage of the fact
> that skb_ext already hook ups to all the right places where we
> free/clone skbs and add the new tracepoints there.

fair enough.

> If we did it like that, we could then just gate on a bit from
> skb->active_extensions, and just handle activating the bpf_skb_ext in a
> special way, meaning it wouldn't result in allocating the skb_ext slab.
>
> Let me give it a try and get back to you.

Thanks!