Thread (20 messages) 20 messages, 3 authors, 2026-01-08

Re: [PATCH bpf-next v3 00/17] Decouple skb metadata tracking from MAC header offset

From: Jakub Kicinski <kuba@kernel.org>
Date: 2026-01-08 15:47:44
Also in: bpf

On Wed, 07 Jan 2026 15:28:00 +0100 Jakub Sitnicki wrote:
This series continues the effort to provide reliable access to xdp/skb
metadata from BPF context on the receive path. We have recently talked
about it at Plumbers [1].

Currently skb metadata location is tied to the MAC header offset:

  [headroom][metadata][MAC hdr][L3 pkt]
                      ^
                      skb_metadata_end = head + mac_header

This design breaks on L2 decapsulation (VLAN, GRE, etc.) when the MAC
offset is reset. The naive fix is to memmove metadata on every decap path,
but we can avoid this cost by tracking metadata position independently.

Introduce a dedicated meta_end field in skb_shared_info that records where
metadata ends relative to skb->head:

  [headroom][metadata][gap][MAC hdr][L3 pkt]
                     ^
                     skb_metadata_end = head + meta_end
                     
This allows BPF dynptr access (bpf_dynptr_from_skb_meta()) to work without
memmove. For skb->data_meta pointer access, which expects metadata
immediately before skb->data, make the verifier inject realignment code in
TC BPF prologue.
I don't understand what semantics for the buffer layout you're trying
to establish, we now have "headroom" and "gap"?

	[headroom][metadata][gap][packet]

You're not solving the encap side either, skb_push() will still happily
encroach on the metadata. Feel like duct tape, we can't fundamentally
update the layout of the skb without updating all the helpers.
metadata works perfectly fine for its intended use case - passing info
about the frame from XDP offload to XDP and then to TC.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help