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