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: <74582905-b884-41f3-8c46-761631c06c22@kernel.org>
Date: Wed, 15 Jan 2025 11:23:37 +0100
From: Jesper Dangaard Brouer <hawk@...nel.org>
To: Florian Kauer <florian.kauer@...utronix.de>,
 Marcus Wichelmann <marcus.wichelmann@...zner-cloud.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



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/

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?

>> 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
>>
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ