Am 12.02.24 um 15:35 schrieb Florian Kauer:
On 12.02.24 14:41, Toke Høiland-Jørgensen wrote:Florian Kauer <florian.kauer@xxxxxxxxxxxxx> writes:2. For the RX side, the metadata is documented as "XDP RX Metadata" (https://docs.kernel.org/networking/xdp-rx-metadata.html), while for TX it is "AF_XDP TX Metadata" (https://www.kernel.org/doc/html/next/networking/xsk-tx-metadata.html). That seems to imply that TX metadata only works for AF_XDP, but not for direct redirection. Is there a reason for that?Well, IIRC, AF_XDP was the most pressing use case, and no one has gotten around to extending this to the regular XDP forwarding path yet.Ok, that is fine. I had the fear that there is some fundamental problem that prevents to implement this.
Hi, are there any updates on this? I'm currently looking into this as well. I'd like to have a way to enable the TX checksum offload when redirecting from one device to another. Stanislav Fomichev already implemented [1] the TX offload support for the AF_XDP use case (thanks for that), but for now, this cannot be used for "regular" redirects. I'm currently in a position where I can invest some work into this, but figured it would make sense to ask you first: Do you already have concrete plans or ideas in mind, how the API to trigger the TX offloads should look like? I have seen the talk [2] from Jesper about this, but I'm not sure if the proposals in there are still up to date. I think it could be possible to introduce a program flag, just like `BPF_F_XDP_HAS_FRAGS`, and if this flag is set, interpret a part of the metadata area as a `struct xsk_tx_metadata`. Then, the code to apply the offloads from that struct when xmit-ing the frame could be reused, as it is already implemented in `mlx5e_xmit_xdp_frame` for example. But the "xsk" in the struct name may be a bit confusing. :/ Do you think this could work or could you guide me into a direction that may have a chance to be upstreamable? Also, is there any recent work on this that I should know off? Thanks! Marcus Wichelmann Hetzner Cloud GmbH [1] https://lore.kernel.org/bpf/20231127190319.1190813-3-sdf@xxxxxxxxxx/ [2] https://lpc.events/event/16/contributions/1362/attachments/1056/2017/xdp-hints-lpc2022.pdf