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

[Jakub Sitnicki <jakub@cloudflare.com>]

On Fri, Sep 25, 2026 at 08:27 PM GMT, Alexei Starovoitov wrote:
> 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.

The benchmarks from Friday were wrong. I got bit by KVM halt polling,
which was randomly inflating the runtime cost by preventing batching.

The correct results - as in reproducible and with lower variance - are
the other way around - BPF skb ext is cheaper CPU-wise than gated skb
tracepoints. Please see:

https://patch.msgid.link/20260928-bpf-meta-gated-tracepoints-v1-0-844dbf3e1edf@cloudflare.com

Despite that, I agree that the tracepoint approach is tempting from the
UX PoV.

While an skb extension seems like a natural continuation of the XDP/TC
metadata pattern, I think that model is not a great fit for skbs
traveling through the network stack.

For XDP hook, there will be usually a single owning process of the
attached program, I think. While TC, cgroup, tracepoints can have
independent program owners, each wanting to associate their own piece of
metadata with the skb.


I can iterate on on cosmetic aspects so that we don't have blocks like:

        if (reason == SKB_CONSUMED)
                trace_consume_skb(...)
        else
                trace_kfree_skb(..., reason, ...)
        skb_maybe_trace_free(..., reason, ...)

... in a couple places where they appear in v1.

Thanks for feedback.