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

[Jesper Dangaard Brouer <hawk@kernel.org>]

On 14/08/2026 10.14, Jakub Sitnicki wrote:
> [I realize net-next closes soon. Posting only to collect more feedback.]
> 
> Please see the RFC cover letter for the overview [1].
> I will focus here just on the latest developments.
> 
> 1) Based on feedback from the RFC - the BPF skb extension is *no longer
> scrubbed* on tunnel encap/decap or veth traversal. There is also *no
> mechanism* to enable scrubbing as we don't seem to have a use case for it.
> 
> 2) Since the RFC I've enabled access to BPF skb extension for the remaining
> BPF program types which operate on skbs, namely netfilter, lwt family, and
> - everyone's favorite - sk_skb.
> 
> Outside the patch set, two things happened:
> 
> 3) At NetConf 2026 Kuniyuki presented effectively the same idea with a use
> case in mind to attach metadata to packets on egress (IIRC). Hoping for
> feedback if this meets your needs as well.
> 
> 4) At BPF Summit 2026, Alexei asked - I'm paraphrasing: What percentage of
> skbs will carry metadata in our workload? This determines if the cost of
> attaching a tracing prog to consume_skb gets amortized. We've run
> experiments and have some answers.
> 
> If bpf skb ext existed today, we would adopt it to attach metadata to
> incoming TCP connections and ingress UDP packets to CDN to identify flows
> that have been forwarded from one PoP to another.
> 
> Based on stats from a production node where we've been testing this patch
> set, the fraction of skbs that would carry the metadata is <1% (~0.7%):
> 
> ```
> 923m16$ sudo perf stat -a -r 10 \
>              -e skb:consume_skb -e skb:kfree_skb \
>              -e probe:skb_ext_add -- sleep 1
> 
>   Performance counter stats for 'system wide' (10 runs):
> 
>             334,256      skb:consume_skb                            ( +-  1.63% )
>               1,525      skb:kfree_skb                              ( +-  4.09% )
>               2,218      probe:skb_ext_add                          ( +- 18.58% )
> 
>             1.02305 +- 0.00243 seconds time elapsed  ( +-  0.24% )
> ```
> 
> I expect that even if we adopted bpf skb ext for other use cases we have in
> mind, like labeling egress CDN packets with a customer identifier, we would
> attach metadata only to around 5% of all skbs in flight.
> 
> We've run an experiment to evaluate this patch set - bpf skb extension -
> against the alternative - using a BPF map keyed by &skb (LRU_HASH) to stash
> metadata plus consume/kfree_skb tracepoint programs to clean up the
> entries.
> 
> To do that we've modified the CDN component that labels the incoming
> connections forwarded from another PoP:
> 
> - with bpf skb ext, BPF progs involved in processing consumed 7.5..10 CPU%,
> - with BPF map + consume/kfree_skb tp, the overhead was between 15..20 CPU%
> 
> Not surprising considering the low fraction of skbs we attach metadata to.
> (For graphs see slides 30 & 40 from our presentation at Netdev 0x1A [2].)
> 

It seems quite clear to me that the kfree_skb tracepoint approach have
too high overhead.  Simply due to frequency as it getting invoked for
ALL packets in the system.

--Jesper




> [1] https://patch.msgid.link/20260714-bpf-meta-inside-skb-ext-v1-0-5871c07a8dd6@cloudflare.com
> [2] https://github.com/jsitnicki/talks/blob/5d64c151f4dc0c38b2832fdcbce7284ec93fdca2/Netdev%200x1A%20-%20Thrice%20the%20charm%20-%20an%20skb%20extension%20for%20BPF%20metadata.pdf
>