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

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:

quoted

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

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.