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.