From: Jakub Sitnicki <jakub@cloudflare.com>
To: Martin KaFai Lau <martin.lau@linux.dev>
Cc: "Alexei Starovoitov" <ast@kernel.org>,
"Andrii Nakryiko" <andrii@kernel.org>,
"Arthur Fabre" <arthur@arthurfabre.com>,
"Daniel Borkmann" <daniel@iogearbox.net>,
"Eduard Zingerman" <eddyz87@gmail.com>,
"Eric Dumazet" <edumazet@google.com>,
"Jakub Kicinski" <kuba@kernel.org>,
"Jesper Dangaard Brouer" <hawk@kernel.org>,
"Jesse Brandeburg" <jbrandeburg@cloudflare.com>,
"Joanne Koong" <joannelkoong@gmail.com>,
"Lorenzo Bianconi" <lorenzo@kernel.org>,
"Toke Høiland-Jørgensen" <thoiland@redhat.com>,
"Yan Zhai" <yan@cloudflare.com>,
kernel-team@cloudflare.com, netdev@vger.kernel.org,
"Stanislav Fomichev" <sdf@fomichev.me>,
bpf@vger.kernel.org
Subject: Re: [PATCH bpf-next v4 1/8] bpf: Add dynptr type for skb metadata
Date: Thu, 24 Jul 2025 13:56:02 +0200 [thread overview]
Message-ID: <87pldpx0od.fsf@cloudflare.com> (raw)
In-Reply-To: <00a19156-cf90-48ca-be91-6c218b317044@linux.dev> (Martin KaFai Lau's message of "Wed, 23 Jul 2025 18:54:53 -0700")
On Wed, Jul 23, 2025 at 06:54 PM -07, Martin KaFai Lau wrote:
> On 7/23/25 10:36 AM, Jakub Sitnicki wrote:
>> More importantly, it abstracts away the fact where the storage for the
>> custom metadata lives, which opens up the way to persist the metadata by
>> relocating it as the skb travels through the network stack layers.
>> A notable difference between the skb and the skb_meta dynptr is that writes
>> to the skb_meta dynptr don't invalidate either skb or skb_meta dynptr
>> slices, since they cannot lead to a skb->head reallocation.
>
> There is not much visibility on how the metadata will be relocated, so trying to
> think out loud. The "no invalidation after bpf_dynptr_write(&meta_dynptr, ..."
> behavior will be hard to change in the future. Will this still hold in the
> future when the metadata can be preserved?
>
> Also, following up on Kuba's point about clone skb, what if the bpf prog wants
> to write metadata to a clone skb in the future by using bpf_dynptr_write?
Good point. If we decide to implement a copy-on-write in the future,
then this will be a problem. Why tie our hands if it's not a huge
nuissance for the user? Let me restrict it.
next prev parent reply other threads:[~2025-07-24 11:56 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-23 17:36 [PATCH bpf-next v4 0/8] Add a dynptr type for skb metadata for TC BPF Jakub Sitnicki
2025-07-23 17:36 ` [PATCH bpf-next v4 1/8] bpf: Add dynptr type for skb metadata Jakub Sitnicki
2025-07-24 1:54 ` Martin KaFai Lau
2025-07-24 11:56 ` Jakub Sitnicki [this message]
2025-07-23 17:36 ` [PATCH bpf-next v4 2/8] bpf: Enable read/write access to skb metadata through a dynptr Jakub Sitnicki
2025-07-23 21:58 ` Eduard Zingerman
2025-07-24 0:02 ` Martin KaFai Lau
2025-07-24 9:44 ` Jakub Sitnicki
2025-07-24 0:30 ` Jakub Kicinski
2025-07-24 11:53 ` Jakub Sitnicki
2025-07-24 15:52 ` Martin KaFai Lau
2025-07-24 19:43 ` Jakub Sitnicki
2025-07-25 9:43 ` Jakub Sitnicki
2025-07-25 14:34 ` Jakub Kicinski
2025-07-23 17:36 ` [PATCH bpf-next v4 3/8] selftests/bpf: Cover verifier checks for skb_meta dynptr type Jakub Sitnicki
2025-07-23 17:36 ` [PATCH bpf-next v4 4/8] selftests/bpf: Pass just bpf_map to xdp_context_test helper Jakub Sitnicki
2025-07-23 17:36 ` [PATCH bpf-next v4 5/8] selftests/bpf: Parametrize test_xdp_context_tuntap Jakub Sitnicki
2025-07-23 17:36 ` [PATCH bpf-next v4 6/8] selftests/bpf: Cover read access to skb metadata via dynptr Jakub Sitnicki
2025-07-23 17:36 ` [PATCH bpf-next v4 7/8] selftests/bpf: Cover write " Jakub Sitnicki
2025-07-23 17:36 ` [PATCH bpf-next v4 8/8] selftests/bpf: Cover read/write to skb metadata at an offset Jakub Sitnicki
2025-07-23 22:02 ` Eduard Zingerman
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=87pldpx0od.fsf@cloudflare.com \
--to=jakub@cloudflare.com \
--cc=andrii@kernel.org \
--cc=arthur@arthurfabre.com \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=edumazet@google.com \
--cc=hawk@kernel.org \
--cc=jbrandeburg@cloudflare.com \
--cc=joannelkoong@gmail.com \
--cc=kernel-team@cloudflare.com \
--cc=kuba@kernel.org \
--cc=lorenzo@kernel.org \
--cc=martin.lau@linux.dev \
--cc=netdev@vger.kernel.org \
--cc=sdf@fomichev.me \
--cc=thoiland@redhat.com \
--cc=yan@cloudflare.com \
/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;
as well as URLs for NNTP newsgroup(s).