netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: Jesper Dangaard Brouer <hawk@kernel.org>
Cc: Lorenzo Bianconi <lorenzo@kernel.org>,
	Stanislav Fomichev <stfomichev@gmail.com>,
	bpf@vger.kernel.org, netdev@vger.kernel.org,
	Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <borkmann@iogearbox.net>,
	Eric Dumazet <eric.dumazet@gmail.com>,
	"David S. Miller" <davem@davemloft.net>,
	Paolo Abeni <pabeni@redhat.com>,
	sdf@fomichev.me, kernel-team@cloudflare.com,
	arthur@arthurfabre.com, jakub@cloudflare.com,
	Jesse Brandeburg <jbrandeburg@cloudflare.com>
Subject: Re: [PATCH bpf-next V2 0/7] xdp: Allow BPF to set RX hints for XDP_REDIRECTed packets
Date: Thu, 17 Jul 2025 18:25:34 -0700	[thread overview]
Message-ID: <20250717182534.4f305f8a@kernel.org> (raw)
In-Reply-To: <fbb026f9-54cf-49ba-b0dc-0df0f54c6961@kernel.org>

On Thu, 17 Jul 2025 15:08:49 +0200 Jesper Dangaard Brouer wrote:
> Let me explain why it is a bad idea of writing into the RX descriptors.
> The DMA descriptors are allocated as coherent DMA (dma_alloc_coherent).
> This is memory that is shared with the NIC hardware device, which
> implies cache-line coherence.  NIC performance is tightly coupled to
> limiting cache misses for descriptors.  One common trick is to pack more
> descriptors into a single cache-line.  Thus, if we start to write into
> the current RX-descriptor, then we invalidate that cache-line seen from
> the device, and next RX-descriptor (from this cache-line) will be in an
> unfortunate coherent state.  Behind the scene this might lead to some
> extra PCIe transactions.
> 
> By writing to the xdp_frame, we don't have to modify the DMA descriptors
> directly and risk invalidating cache lines for the NIC.

I thought you main use case is redirected packets. In which case it's
the _remote_ end that's writing its metadata, if it's veth it's
obviously not going to be doing it into DMA coherent memory.

The metadata travels between the source and destination in program-
-defined format.

> Thanks for the feedback. I can see why you'd be concerned about adding
> another adhoc scheme or making xdp_frame grow into a "para-skb".
> 
> However, I'd like to frame this as part of a long-term plan we've been
> calling the "mini-SKB" concept. This isn't a new idea, but a
> continuation of architectural discussions from as far back as [2016].

My understanding is that while this was floated as a plan by some,
nobody came up with a clean way of implementing it.

  reply	other threads:[~2025-07-18  1:25 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-02 14:58 [PATCH bpf-next V2 0/7] xdp: Allow BPF to set RX hints for XDP_REDIRECTed packets Jesper Dangaard Brouer
2025-07-02 14:58 ` [PATCH bpf-next V2 1/7] net: xdp: Add xdp_rx_meta structure Jesper Dangaard Brouer
2025-07-17  9:19   ` Jakub Sitnicki
2025-07-17 14:40     ` Jesper Dangaard Brouer
2025-07-18 10:33       ` Jakub Sitnicki
2025-07-02 14:58 ` [PATCH bpf-next V2 2/7] selftests/bpf: Adjust test for maximum packet size in xdp_do_redirect Jesper Dangaard Brouer
2025-07-02 14:58 ` [PATCH bpf-next V2 3/7] net: xdp: Add kfuncs to store hw metadata in xdp_buff Jesper Dangaard Brouer
2025-07-03 11:41   ` Jesper Dangaard Brouer
2025-07-03 12:26     ` Lorenzo Bianconi
2025-07-02 14:58 ` [PATCH bpf-next V2 4/7] net: xdp: Set skb hw metadata from xdp_frame Jesper Dangaard Brouer
2025-07-02 14:58 ` [PATCH bpf-next V2 5/7] net: veth: Read xdp metadata from rx_meta struct if available Jesper Dangaard Brouer
2025-07-17 12:11   ` Jakub Sitnicki
2025-07-02 14:58 ` [PATCH bpf-next V2 6/7] bpf: selftests: Add rx_meta store kfuncs selftest Jesper Dangaard Brouer
2025-07-23  9:24   ` Bouska, Zdenek
2025-07-02 14:58 ` [PATCH bpf-next V2 7/7] net: xdp: update documentation for xdp-rx-metadata.rst Jesper Dangaard Brouer
2025-07-02 16:05 ` [PATCH bpf-next V2 0/7] xdp: Allow BPF to set RX hints for XDP_REDIRECTed packets Stanislav Fomichev
2025-07-03 11:17   ` Jesper Dangaard Brouer
2025-07-07 14:40     ` Stanislav Fomichev
2025-07-09  9:31       ` Lorenzo Bianconi
2025-07-11 16:04         ` Stanislav Fomichev
2025-07-16 11:17           ` Lorenzo Bianconi
2025-07-16 21:20             ` Jakub Kicinski
2025-07-17 13:08               ` Jesper Dangaard Brouer
2025-07-18  1:25                 ` Jakub Kicinski [this message]
2025-07-18 10:56                   ` Jesper Dangaard Brouer
2025-07-22  1:13                     ` Jakub Kicinski
2025-07-28 10:53                       ` Lorenzo Bianconi
2025-07-28 16:29                         ` Jakub Kicinski
2025-07-29 11:15                           ` Jesper Dangaard Brouer
2025-07-29 19:47                             ` Martin KaFai Lau
2025-07-31 16:27                               ` Jesper Dangaard Brouer
2025-08-01 20:38                                 ` Jakub Kicinski
2025-08-04 13:18                                   ` Jesper Dangaard Brouer
2025-08-06  0:28                                     ` Jakub Kicinski
2025-08-07 18:26                                       ` Jesper Dangaard Brouer
2025-08-06  1:24                                     ` Martin KaFai Lau
2025-08-07 19:07                                       ` Jesper Dangaard Brouer
2025-08-13  2:59                                         ` Martin KaFai Lau
2025-07-31 21:18                           ` Lorenzo Bianconi
2025-08-01 20:40                             ` Jakub Kicinski
2025-08-05 13:18                               ` Lorenzo Bianconi
2025-08-05 23:54                                 ` Jakub Kicinski
2025-07-18  9:55                 ` Lorenzo Bianconi

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

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

  git send-email \
    --in-reply-to=20250717182534.4f305f8a@kernel.org \
    --to=kuba@kernel.org \
    --cc=arthur@arthurfabre.com \
    --cc=ast@kernel.org \
    --cc=borkmann@iogearbox.net \
    --cc=bpf@vger.kernel.org \
    --cc=davem@davemloft.net \
    --cc=eric.dumazet@gmail.com \
    --cc=hawk@kernel.org \
    --cc=jakub@cloudflare.com \
    --cc=jbrandeburg@cloudflare.com \
    --cc=kernel-team@cloudflare.com \
    --cc=lorenzo@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=sdf@fomichev.me \
    --cc=stfomichev@gmail.com \
    /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;
as well as URLs for NNTP newsgroup(s).