XDP hardware hints discussion mail archive
 help / color / mirror / Atom feed
From: Marcus Wichelmann <marcus.wichelmann@hetzner-cloud.de>
To: "Jesper Dangaard Brouer" <hawk@kernel.org>,
	"Florian Kauer" <florian.kauer@linutronix.de>,
	"Toke Høiland-Jørgensen" <toke@toke.dk>,
	xdp-hints@xdp-project.net, xdp-newbies@vger.kernel.org
Cc: Stanislav Fomichev <sdf@fomichev.me>,
	Arthur Fabre <afabre@cloudflare.com>,
	Jakub Sitnicki <jakub@cloudflare.com>,
	Netdev <netdev@vger.kernel.org>,
	kernel-team <kernel-team@cloudflare.com>
Subject: [xdp-hints] Re: XDP Redirect and TX Metadata
Date: Wed, 15 Jan 2025 11:30:54 +0100	[thread overview]
Message-ID: <8f2e68bb-af19-4a65-8fe1-1a0f70c0caf5@hetzner-cloud.de> (raw)
In-Reply-To: <173693662447.106245.11283936919402528400@gauss>

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@linutronix.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

      parent reply	other threads:[~2025-01-15 10:31 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-12  8:27 [xdp-hints] " Florian Kauer
2024-02-12 13:41 ` [xdp-hints] " Toke Høiland-Jørgensen
2024-02-12 14:35   ` Florian Kauer
2024-02-13 13:00     ` Toke Høiland-Jørgensen
2025-01-14 16:47     ` Marcus Wichelmann
2025-01-14 18:07       ` Florian Kauer
2025-01-15 10:23         ` Jesper Dangaard Brouer
     [not found]         ` <173693662447.106245.11283936919402528400@gauss>
2025-01-15 10:30           ` Marcus Wichelmann [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.xdp-project.net/postorius/lists/xdp-hints.xdp-project.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8f2e68bb-af19-4a65-8fe1-1a0f70c0caf5@hetzner-cloud.de \
    --to=marcus.wichelmann@hetzner-cloud.de \
    --cc=afabre@cloudflare.com \
    --cc=florian.kauer@linutronix.de \
    --cc=hawk@kernel.org \
    --cc=jakub@cloudflare.com \
    --cc=kernel-team@cloudflare.com \
    --cc=netdev@vger.kernel.org \
    --cc=sdf@fomichev.me \
    --cc=toke@toke.dk \
    --cc=xdp-hints@xdp-project.net \
    --cc=xdp-newbies@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox