Netdev List
 help / color / mirror / Atom feed
From: Stanislav Fomichev <sdf.kernel@gmail.com>
To: Jakub Sitnicki <jakub@cloudflare.com>
Cc: netdev@vger.kernel.org, bpf@vger.kernel.org,  kernel-team@cloudflare.com
Subject: Re: [PATCH RFC net-next 1/6] bpf: Introduce per-packet metadata storage for BPF programs
Date: Thu, 16 Jul 2026 05:10:12 -0700	[thread overview]
Message-ID: <aljJ1u-_1CBBF8Ha@devvm7509.cco0.facebook.com> (raw)
In-Reply-To: <20260714-bpf-meta-inside-skb-ext-v1-1-5871c07a8dd6@cloudflare.com>

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?

  reply	other threads:[~2026-07-16 12:11 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-14 17:48 [PATCH RFC net-next 0/6] skb extension for BPF metadata Jakub Sitnicki
2026-07-14 17:48 ` [PATCH RFC net-next 1/6] bpf: Introduce per-packet metadata storage for BPF programs Jakub Sitnicki
2026-07-16 12:10   ` Stanislav Fomichev [this message]
2026-07-16 12:35     ` Jakub Sitnicki
2026-07-14 17:48 ` [PATCH RFC net-next 2/6] bpf: Allow access to bpf_sock_ops_kern->skb Jakub Sitnicki
2026-07-14 17:48 ` [PATCH RFC net-next 3/6] bpf: Allow skb extensions to survive packet scrubbing Jakub Sitnicki
2026-07-16 12:11   ` Stanislav Fomichev
2026-07-16 12:59     ` Jakub Sitnicki
2026-07-16 15:06       ` Jason Xing
2026-07-14 17:48 ` [PATCH RFC net-next 4/6] selftests/bpf: Add tests for bpf_dynptr_from_skb_ext Jakub Sitnicki
2026-07-14 17:48 ` [PATCH RFC net-next 5/6] selftests/bpf: Test skb_ext scrubbing across tunnels and veths Jakub Sitnicki
2026-07-14 17:48 ` [PATCH RFC net-next 6/6] selftests/bpf: Use non-trivial test payload in xdp_context tests Jakub Sitnicki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aljJ1u-_1CBBF8Ha@devvm7509.cco0.facebook.com \
    --to=sdf.kernel@gmail.com \
    --cc=bpf@vger.kernel.org \
    --cc=jakub@cloudflare.com \
    --cc=kernel-team@cloudflare.com \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox