On Wed, 16 Jul 2025 13:17:53 +0200 Lorenzo Bianconi wrote:

quoted

quoted

I can't see what the non-redirected use-case could be. Can you please provide
more details?
Moreover, can it be solved without storing the rx_hash (or the other
hw-metadata) in a non-driver specific format?  

Having setters feels more generic than narrowly solving only the redirect,
but I don't have a good use-case in mind.
  

quoted

Storing the hw-metadata in some of hw-specific format in xdp_frame will not
allow to consume them directly building the skb and we will require to decode
them again. What is the upside/use-case of this approach? (not considering the
orthogonality with the get method).  

If we add the store kfuncs to regular drivers, the metadata  won't be stored
in the xdp_frame; it will go into the rx descriptors so regular path that
builds skbs will use it.  

IIUC, the described use-case would be to modify the hw metadata via a
'setter' kfunc executed by an eBPF program bounded to the NIC and to store
the new metadata in the DMA descriptor in order to be consumed by the driver
codebase building the skb, right?
If so:
- we can get the same result just storing (running a kfunc) the modified hw
  metadata in the xdp_buff struct using a well-known/generic layout and
  consume it in the driver codebase (e.g. if the bounded eBPF program
  returns XDP_PASS) using a generic xdp utility routine. This part is not in
  the current series.
- Using this approach we are still not preserving the hw metadata if we pass
  the xdp_frame to a remote CPU returning XDP_REDIRCT (we need to add more
  code)
- I am not completely sure if can always modify the DMA descriptor directly
  since it is DMA mapped.

What do you think?

FWIW I commented on an earlier revision to similar effect as Stanislav.
To me the main concern is that we're adding another adhoc scheme, and
are making xdp_frame grow into a para-skb. We added XDP to make raw
packet access fast, now we're making drivers convert metadata twice :/