netdev - Re: [xdp-hints] Re: XDP Redirect and TX Metadata

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>] [day] [month] [year] [list]

Message-ID: <8f2e68bb-af19-4a65-8fe1-1a0f70c0caf5@hetzner-cloud.de>
Date: Wed, 15 Jan 2025 11:30:54 +0100
From: Marcus Wichelmann <marcus.wichelmann@...zner-cloud.de>
To: Jesper Dangaard Brouer <hawk@...nel.org>,
 Florian Kauer <florian.kauer@...utronix.de>,
 Toke Høiland-Jørgensen <toke@...e.dk>,
 xdp-hints@...-project.net, xdp-newbies@...r.kernel.org
Cc: Stanislav Fomichev <sdf@...ichev.me>, Arthur Fabre
 <afabre@...udflare.com>, Jakub Sitnicki <jakub@...udflare.com>,
 Netdev <netdev@...r.kernel.org>, kernel-team <kernel-team@...udflare.com>
Subject: Re: [xdp-hints] Re: XDP Redirect and TX Metadata

Hi!

Am 15.01.25 um 11:23 schrieb Jesper Dangaard Brouer via xdp-hints:
> 
> On 14/01/2025 19.07, Florian Kauer wrote:
>> Hi Marcus,
>>
>> On 1/14/25 17:47, Marcus Wichelmann wrote:
>>> 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@...utronix.de> 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 am still interested, but have no implementation planned short- or mid-term.
>> So, looking forward to your implementation 🙂
>>
>> Greetings,
>> Florian
>>
>>>
>>> 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.
> 
> My talk is outdated. My co-workers Arthur and Jakub did a
> presentation[3] at LPC2024.  Alexei liked the Compressed Key-Value store
> idea from that presentation[3].   So, we are currently working on a
> Compressed Key-Value store that Arthur named "traits".  We are almost
> done benchmarking this, see traits0N_* documents in [4].
> 
> [3] https://lpc.events/event/18/contributions/1935/
> [4] https://github.com/xdp-project/xdp-project/blob/main/areas/hints/

Ah, thanks, I will look into this. I have seen some patches about the traits but had not realized what this is for. Great!

> Our implementation is primarily focused on the RX side, and transferring  RX hardware metadata to CPUMAP+veth when doing XDP_REDIRECT.
> 
> You ask is about TX side, right?

Yes. Would the traits work for the TX metadata as well?

I should probably wait for it then and implement a temporary solution for our use cases in the meantime.

> 
>>> 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@google.com/
>>> [2] https://lpc.events/event/16/contributions/1362/attachments/1056/2017/xdp-hints-lpc2022.pdf
>>>

Marcus