Re: [PATCH net-next v2 03/14] bpf: Make BPF skb extension survive packet scrubbing

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

On Fri Sep 25, 2026 at 8:20 PM UTC, Jakub Kicinski wrote:
> On Fri, 25 Sep 2026 19:51:37 +0000 Alexei Starovoitov wrote:
>> On Fri, Sep 25, 2026 at 12:18 PM Jakub Kicinski <kuba@kernel.org> wrote:
>> > Instead of improving the existing infra we're adding more BPF-specific
>> > glue and another bit to the skb. Matter of perspective I suppose :/  
>> 
>> skb_ext version needs a bit too. SKB_EXT_BPF is the 8th id, so it takes
>> the last bit of u8 active_extensions.
>> skbuff_ext_cache object is sized for all ids, so it also grows by
>> BPF_SKB_EXT_SIZE for xfrm, mptcp, psp whether bpf is used or not.
>> 
>> As I said earlier skb_ext is fine from bpf pov. If it can be made as
>> cheap as bit + tracepoint I don't mind it at all.
>> Which part of skb_ext would you improve?
>
> Mostly allocation speed. Either a small per-CPU cache like we have
> for skbs or let the scalar matadata fields live inside the skb.

makes sense to me. Speeding up generic infra is always a good thing.

> That said, the selective tracing approach is also tempting.
> It'd be great if we could have that for sockets.
> Could we possibly think of a way to build that into tracepoints
> instead of having the open coded
>
> obj_maybe_trace_bla()
> {
> 	if (obj->trace)
> 		trace_bla();
> }
>
> Having both:
>
> 	skb_maybe_trace_free(skb, SKB_CONSUMED);
> 	skb_release_data(skb, SKB_CONSUMED);

with a 3rd enum argument for different use cases?
As a way to generalize different bits / different users?

Also makes sense.