Re: [PATCH RFC net-next 1/6] bpf: Introduce per-packet metadata storage for BPF programs

[Jakub Sitnicki <jakub@cloudflare.com>]

On Thu, Jul 16, 2026 at 05:10 AM -07, Stanislav Fomichev wrote:
> On 07/14, Jakub Sitnicki wrote:
>> BPF programs attached at different points in the network stack have no way
>> to pass data between each other on a per-packet basis, other than by
>> stashing it into a shared BPF map. xdp/skb->data_meta works for XDP-to-TC
>> handoff, but is not available to programs running at later hooks like
>> cgroup/skb, sock_ops, socket filters, tracing or LSM.
>> 
>> Add a new skb extension (struct bpf_skb_ext) that provides up to 256 bytes
>> of per-packet storage. Size is configurable at build time though the
>> CONFIG_BPF_SKB_EXT_SIZE option. The storage is embedded inside the
>> extension chunk itself.
>> 
>> Expose the storage to BPF programs via bpf_dynptr_from_skb_ext() kfunc.
>> The caller passes BPF_SKB_EXT_F_CREATE to allocate or COW (unshare) the
>> extension and get a read-write dynptr. Without the flag, it gets a
>> read-only dynptr to the existing extension, or -ENOENT if none exists.
>> 
>> Guard the feature behind a new CONFIG_BPF_SKB_EXT option.
>> 
>> Signed-off-by: Jakub Sitnicki <jakub@cloudflare.com>
>> ---
>>  include/linux/bpf.h      |  10 ++++
>>  include/linux/filter.h   |  26 ++++++++++
>>  include/linux/skbuff.h   |   3 ++
>>  include/uapi/linux/bpf.h |   5 ++
>>  kernel/bpf/helpers.c     |   7 +++
>>  kernel/bpf/log.c         |   2 +
>>  kernel/bpf/verifier.c    |  10 +++-
>>  net/Kconfig              |  20 ++++++++
>>  net/core/filter.c        | 129 +++++++++++++++++++++++++++++++++++++++++++++++
>>  net/core/skbuff.c        |   3 ++
>>  10 files changed, 214 insertions(+), 1 deletion(-)
>> 
>> diff --git a/include/linux/bpf.h b/include/linux/bpf.h
>> index 7719f6528445..6b918a5b61bf 100644
>> --- a/include/linux/bpf.h
>> +++ b/include/linux/bpf.h
>> @@ -1484,6 +1484,8 @@ enum bpf_dynptr_type {
>>  	BPF_DYNPTR_TYPE_SKB_META,
>>  	/* Underlying data is a file */
>>  	BPF_DYNPTR_TYPE_FILE,
>> +	/* Underlying data is a bpf_skb_ext chunk */
>> +	BPF_DYNPTR_TYPE_SKB_EXT,
>>  };
>>  
>>  int bpf_dynptr_check_size(u64 size);
>> @@ -4209,4 +4211,12 @@ static inline int bpf_map_check_op_flags(struct bpf_map *map, u64 flags, u64 all
>>  	return 0;
>>  }
>>  
>> +#ifdef CONFIG_BPF_SKB_EXT
>> +
>> +struct bpf_skb_ext {
>> +	u8 buf[CONFIG_BPF_SKB_EXT_SIZE] __aligned(8);
>> +};
>
> Can we do a dynamic size from the start? Say, some sysfs knob, 0 by
> default. Once written, it's locks in the size and can't be changed.
> Then your new 'flags' field can be used to indicate whether the area
> actually has been allocated or not?

Thanks for feedback. Dynamic size would be ideal.

We're limited by skb extensions implementation here, which needs to know
the (maximum) size of each skb extension chunk at init time [1].

That said, there's been hallway discussion at Netdev, that we should
look into making skb_ext allocate memory just for activated extensions
and realloc as needed, as extensions are gaining more users.

Current implementation (allocate space for every available extension) is
wasteful, as you have extension combos which are not possible (won't be
active at the same time), like IPsec and MPTCP and CAN.

IOW, build-time config is what is doable today. Having a sysctl knob
doesn't buy us much. But we have a path to lift that constraint later
(if we don't mess up the BPF API).

[1] https://elixir.bootlin.com/linux/v7.2-rc3/source/net/core/skbuff.c#L5171