On Thu, Feb 26, 2026 at 1:16 PM Jakub Sitnicki [off-list ref] wrote:

Previously we have attempted to allow BPF users to attach tens of bytes of
arbitrary data to packets by making XDP/skb metadata area persist across
netstack layers [1].

This approach turned out to be unsuccessful. It would require us to
restrict the layout of skb headroom and patch call sites which modify the
headroom by pushing/pulling the skb->data.

As per Jakub's feedback [2] we're turning our attention to skb extensions
as the new vehicle for passing BPF metadata. skb extensions avoid these
problems by being a separate, opt-in side allocation that doesn't interfere
with skb headroom layout.

With the switch to skb extensions, we are no longer restricted by the
features of XDP metadata, and hence we propose to extend the concept of BPF
local storage to socket buffers - skb local storage.

BPF local storage is an established pattern of attaching arbitrary data
from BPF context to various common kernel entities (sk, task, cgroup,
inode).

And that list of local storages ends with a solid period.
We're not going to add new local storages.
Not for skb and not for anything else.
We rejected it for cred, bdev and other things.

The path forward for such "local storage" like use cases is
to optimize hash, trie, rhashtable, whatever map, so
it's super fast for key == sizeof(void *) and use that
when you need it.
The life cycle of skb already has a tracepoint in the free path.
So do map_update(key=skb, ...) when you need to create such "skb local storage"
and free it from trace_consume/kfree_skb.
Potentially we can add a tracepoint in alloc_skb,
so bpf prog can alloc "skb local storage" there,
and to clone skb, so you can track the storage through clones
if you need to.