From: "Toke Høiland-Jørgensen" <toke@redhat.com>
To: Jakub Sitnicki <jakub@cloudflare.com>,
Jesper Dangaard Brouer <hawk@kernel.org>,
Alexei Starovoitov <ast@kernel.org>,
Jakub Kicinski <kuba@kernel.org>
Cc: Paolo Abeni <pabeni@redhat.com>, Jakub Kicinski <kuba@kernel.org>,
netdev@vger.kernel.org, "David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Simon Horman <horms@kernel.org>,
Michael Chan <michael.chan@broadcom.com>,
Pavan Chebbi <pavan.chebbi@broadcom.com>,
Andrew Lunn <andrew+netdev@lunn.ch>,
Tony Nguyen <anthony.l.nguyen@intel.com>,
Przemek Kitszel <przemyslaw.kitszel@intel.com>,
Saeed Mahameed <saeedm@nvidia.com>,
Leon Romanovsky <leon@kernel.org>,
Tariq Toukan <tariqt@nvidia.com>, Mark Bloch <mbloch@nvidia.com>,
Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
John Fastabend <john.fastabend@gmail.com>,
Stanislav Fomichev <sdf@fomichev.me>,
intel-wired-lan@lists.osuosl.org, bpf@vger.kernel.org,
kernel-team@cloudflare.com,
Jesse Brandeburg <jbrandeburg@cloudflare.com>,
Willem Ferguson <wferguson@cloudflare.com>,
Arthur Fabre <arthur@arthurfabre.com>
Subject: Re: [Intel-wired-lan] [PATCH net-next 00/10] Call skb_metadata_set when skb->data points past metadata
Date: Wed, 14 Jan 2026 12:49:57 +0100 [thread overview]
Message-ID: <878qe01kii.fsf@toke.dk> (raw)
In-Reply-To: <87wm1luusg.fsf@cloudflare.com>
Jakub Sitnicki via Intel-wired-lan <intel-wired-lan@osuosl.org> writes:
> On Tue, Jan 13, 2026 at 07:52 PM +01, Jesper Dangaard Brouer wrote:
>> *BUT* this patchset isn't doing that. To me it looks like a cleanup
>> patchset that simply makes it consistent when skb_metadata_set() called.
>> Selling it as a pre-requirement for doing copy later seems fishy.
>
> Fair point on the framing. The interface cleanup is useful on its own -
> I should have presented it that way rather than tying it to future work.
>
>> Instead of blindly copying XDP data_meta area into a single SKB
>> extension. What if we make it the responsibility of the TC-ingress BPF-
>> hook to understand the data_meta format and via (kfunc) helpers
>> transfer/create the SKB extension that it deems relevant.
>> Would this be an acceptable approach that makes it easier to propagate
>> metadata deeper in netstack?
>
> I think you and Jakub are actually proposing the same thing.
>
> If we can access a buffer tied to an skb extension from BPF, this could
> act as skb-local storage and solves the problem (with some operational
> overhead to set up TC on ingress).
>
> I'd also like to get Alexei's take on this. We had a discussion before
> about not wanting to maintain two different storage areas for skb
> metadata.
>
> That was one of two reasons why we abandoned Arthur's patches and why I
> tried to make the existing headroom-backed metadata area work.
>
> But perhaps I misunderstood the earlier discussion. Alexei's point may
> have been that we don't want another *headroom-backed* metadata area
> accessible from XDP, because we already have that.
>
> Looks like we have two options on the table:
>
> Option A) Headroom-backed metadata
> - Use existing skb metadata area
> - Patch skb_push/pull call sites to preserve it
>
> Option B) Extension-backed metadata
> - Store metadata in skb extension from BPF
> - TC BPF copies/extracts what it needs from headroom-metadata
>
> Or is there an Option C I'm missing?
Not sure if it's really an option C, but would it be possible to
consolidate them using verifier tricks? I.e., the data_meta field in the
__sk_buff struct is really a virtual pointer that the verifier rewrites
to loading an actual pointer from struct bpf_skb_data_end in skb->cb. So
in principle this could be loaded from an skb extension instead with the
BPF programs being none the wiser.
There's the additional wrinkle that the end of the data_meta pointer is
compared to the 'data' start pointer to check for overflow, which
wouldn't work anymore. Not sure if there's a way to make the verifier
rewrite those checks in a compatible way, or if this is even a path we
want to go down. But it would be a pretty neat way to make the whole
thing transparent and backwards compatible, I think :)
Other than that, I like the extention-backed metadata idea!
-Toke
next prev parent reply other threads:[~2026-01-14 11:50 UTC|newest]
Thread overview: 67+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-10 21:05 [PATCH net-next 00/10] Call skb_metadata_set when skb->data points past metadata Jakub Sitnicki
2026-01-10 21:05 ` [Intel-wired-lan] " Jakub Sitnicki via Intel-wired-lan
2026-01-10 21:05 ` [PATCH net-next 01/10] net: Document skb_metadata_set contract with the drivers Jakub Sitnicki
2026-01-10 21:05 ` [Intel-wired-lan] " Jakub Sitnicki via Intel-wired-lan
2026-01-12 11:28 ` Loktionov, Aleksandr
2026-01-12 11:28 ` Loktionov, Aleksandr
2026-01-10 21:05 ` [PATCH net-next 02/10] bnxt_en: Call skb_metadata_set when skb->data points past metadata Jakub Sitnicki
2026-01-10 21:05 ` [Intel-wired-lan] " Jakub Sitnicki via Intel-wired-lan
2026-01-12 11:29 ` Loktionov, Aleksandr
2026-01-12 11:29 ` Loktionov, Aleksandr
2026-01-10 21:05 ` [PATCH net-next 03/10] i40e: " Jakub Sitnicki
2026-01-10 21:05 ` [Intel-wired-lan] " Jakub Sitnicki via Intel-wired-lan
2026-01-12 11:30 ` Loktionov, Aleksandr
2026-01-12 11:30 ` Loktionov, Aleksandr
2026-01-10 21:05 ` [PATCH net-next 04/10] igb: " Jakub Sitnicki
2026-01-10 21:05 ` [Intel-wired-lan] " Jakub Sitnicki via Intel-wired-lan
2026-01-12 11:31 ` Loktionov, Aleksandr
2026-01-12 11:31 ` Loktionov, Aleksandr
2026-01-10 21:05 ` [PATCH net-next 05/10] igc: " Jakub Sitnicki
2026-01-10 21:05 ` [Intel-wired-lan] " Jakub Sitnicki via Intel-wired-lan
2026-01-12 11:31 ` Loktionov, Aleksandr
2026-01-12 11:31 ` Loktionov, Aleksandr
2026-01-10 21:05 ` [PATCH net-next 06/10] ixgbe: " Jakub Sitnicki
2026-01-10 21:05 ` [Intel-wired-lan] " Jakub Sitnicki via Intel-wired-lan
2026-01-12 11:32 ` Loktionov, Aleksandr
2026-01-12 11:32 ` Loktionov, Aleksandr
2026-01-10 21:05 ` [PATCH net-next 07/10] mlx5e: " Jakub Sitnicki
2026-01-10 21:05 ` [Intel-wired-lan] " Jakub Sitnicki via Intel-wired-lan
2026-01-12 11:32 ` Loktionov, Aleksandr
2026-01-12 11:32 ` Loktionov, Aleksandr
2026-01-13 6:08 ` Tariq Toukan
2026-01-13 6:08 ` [Intel-wired-lan] " Tariq Toukan
2026-01-13 12:52 ` Jakub Sitnicki
2026-01-13 12:52 ` [Intel-wired-lan] " Jakub Sitnicki via Intel-wired-lan
2026-01-10 21:05 ` [PATCH net-next 08/10] veth: " Jakub Sitnicki
2026-01-10 21:05 ` [Intel-wired-lan] " Jakub Sitnicki via Intel-wired-lan
2026-01-12 11:33 ` Loktionov, Aleksandr
2026-01-12 11:33 ` Loktionov, Aleksandr
2026-01-10 21:05 ` [PATCH net-next 09/10] xsk: " Jakub Sitnicki
2026-01-10 21:05 ` [Intel-wired-lan] " Jakub Sitnicki via Intel-wired-lan
2026-01-12 11:33 ` Loktionov, Aleksandr
2026-01-12 11:33 ` Loktionov, Aleksandr
2026-01-10 21:05 ` [PATCH net-next 10/10] xdp: " Jakub Sitnicki
2026-01-10 21:05 ` [Intel-wired-lan] " Jakub Sitnicki via Intel-wired-lan
2026-01-12 11:33 ` Loktionov, Aleksandr
2026-01-12 11:33 ` Loktionov, Aleksandr
2026-01-13 3:08 ` [PATCH net-next 00/10] " Jakub Kicinski
2026-01-13 3:08 ` [Intel-wired-lan] " Jakub Kicinski
2026-01-13 12:09 ` Paolo Abeni
2026-01-13 12:09 ` [Intel-wired-lan] " Paolo Abeni
2026-01-13 12:40 ` Jakub Sitnicki
2026-01-13 12:40 ` Jakub Sitnicki via Intel-wired-lan
2026-01-13 18:52 ` Jesper Dangaard Brouer
2026-01-13 18:52 ` [Intel-wired-lan] " Jesper Dangaard Brouer
2026-01-13 20:22 ` Jakub Sitnicki
2026-01-13 20:22 ` Jakub Sitnicki via Intel-wired-lan
2026-01-14 11:49 ` Toke Høiland-Jørgensen [this message]
2026-01-14 12:33 ` Jakub Sitnicki
2026-01-14 12:33 ` Jakub Sitnicki via Intel-wired-lan
2026-01-13 12:33 ` Jakub Sitnicki
2026-01-13 12:33 ` [Intel-wired-lan] " Jakub Sitnicki via Intel-wired-lan
2026-01-22 20:21 ` Martin KaFai Lau
2026-01-22 20:21 ` [Intel-wired-lan] " Martin KaFai Lau
2026-01-25 19:15 ` Jakub Sitnicki
2026-01-25 19:15 ` [Intel-wired-lan] " Jakub Sitnicki via Intel-wired-lan
2026-01-27 19:33 ` Martin KaFai Lau
2026-01-27 19:33 ` [Intel-wired-lan] " Martin KaFai Lau
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=878qe01kii.fsf@toke.dk \
--to=toke@redhat.com \
--cc=andrew+netdev@lunn.ch \
--cc=anthony.l.nguyen@intel.com \
--cc=arthur@arthurfabre.com \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=hawk@kernel.org \
--cc=horms@kernel.org \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=jakub@cloudflare.com \
--cc=jbrandeburg@cloudflare.com \
--cc=john.fastabend@gmail.com \
--cc=kernel-team@cloudflare.com \
--cc=kuba@kernel.org \
--cc=leon@kernel.org \
--cc=mbloch@nvidia.com \
--cc=michael.chan@broadcom.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=pavan.chebbi@broadcom.com \
--cc=przemyslaw.kitszel@intel.com \
--cc=saeedm@nvidia.com \
--cc=sdf@fomichev.me \
--cc=tariqt@nvidia.com \
--cc=wferguson@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.