On 1/13/26 4:33 AM, Jakub Sitnicki wrote:
Good point. I'm hoping we don't have to allocate from
skb_metadata_set(), which does sound prohibitively expensive. Instead
we'd allocate the extension together with the skb if we know upfront
that metadata will be used.
[ Sorry for being late. Have been catching up after holidays. ]
For the sk local storage (which was mentioned in other replies as making
skb metadata to look more like sk local storage), there is a plan (Amery
has been looking into it) to allocate the storage together with sk for
performance reason. This means allocating a larger 'struct sock'. The
extra space will be at the front of sk instead of the end of sk because
of how the 'struct sock' is embedded in tcp_sock/udp_sock/... If skb is
going in the same direction, it should be useful to have a similar
scheme on: upfront allocation and then shared by multiple BPF progs.
The current thinking is to built upon the existing bpf_sk_local_storage
usage. A boot param decides how much BPF space should be allocated for
'struct sock'. When a bpf_sk_storage_map is created (with a new
use_reserve flag), the space will be allocated permanently from the head
space of every sk for this map. The read (from a BPF prog) will be at
one stable offset before a sk. If there is no more head space left, the
map creation will fail. User can decide if it wants to retry without the
'use_reserve' flag.
