Re: [PATCH bpf-next V2 0/7] xdp: Allow BPF to set RX hints for XDP_REDIRECTed packets

[Jakub Kicinski <kuba@kernel.org>]

On Wed, 16 Jul 2025 13:17:53 +0200 Lorenzo Bianconi wrote:
> > > 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.
> >   
> > > 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 :/