netdev - Re: [PATCH bpf-next V1 3/7] net: xdp: Add kfuncs to store hw metadata in xdp

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250616145523.63bd2577@kernel.org>
Date: Mon, 16 Jun 2025 14:55:23 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Jesper Dangaard Brouer <hawk@...nel.org>
Cc: bpf@...r.kernel.org, netdev@...r.kernel.org, lorenzo@...nel.org, Alexei
 Starovoitov <ast@...nel.org>, Daniel Borkmann <borkmann@...earbox.net>,
 Eric Dumazet <eric.dumazet@...il.com>, "David S. Miller"
 <davem@...emloft.net>, Paolo Abeni <pabeni@...hat.com>, sdf@...ichev.me,
 kernel-team@...udflare.com, arthur@...hurfabre.com, jakub@...udflare.com
Subject: Re: [PATCH bpf-next V1 3/7] net: xdp: Add kfuncs to store hw
 metadata in xdp_buff

On Tue, 03 Jun 2025 19:46:08 +0200 Jesper Dangaard Brouer wrote:
> Introduce the following kfuncs to store hw metadata provided by the NIC
> into the xdp_buff struct:
> 
> - rx-hash: bpf_xdp_store_rx_hash
> - rx-vlan: bpf_xdp_store_rx_vlan
> - rx-hw-ts: bpf_xdp_store_rx_ts

My mental model would that these should operate within the "remote XDP".
We have helpers to "get the metadata", now we're adding helpers to "set
the metadata". Should the setting not be simply the inverse of the
getting? Store to driver-specific format?

-> local driver - all the metadata in HW-specific format / descriptors
  -> local XDP - GET and copy data to locally defined md prepend
-> remote drv - CPU map, veth) hooks in its own callbacks and md struct
  -> remote XDP - read the data from md prepend and call SET
-> remote drv - check if XDP set any md in its struct and uses it when
                converting to skb.

Note, this is just the model for the API. We can always introduce
optimizations, like a feature flag that makes the "local" driver output
well known MD struct and have the remote driver pick that up, with
neither XDP calling the helpers. 
But from the model perspective since the GET operations are local to
the driver owning the frame at the time, the SET operations should also
operate on metadata local to the owning driver.

That's my $0.02