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

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:

quoted

On Fri, 25 Sep 2026 19:51:37 +0000 Alexei Starovoitov wrote:

quoted

On Fri, Sep 25, 2026 at 12:18 PM Jakub Kicinski [off-list ref] wrote:

quoted

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.

quoted

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.