From: Jesper Dangaard Brouer <brouer@redhat.com>
To: Magnus Karlsson <magnus.karlsson@gmail.com>
Cc: "Neal Shukla" <nshukla@riotgames.com>,
"Zvi Effron" <zeffron@riotgames.com>,
"Toke Høiland-Jørgensen" <toke@redhat.com>,
Xdp <xdp-newbies@vger.kernel.org>,
"Björn Töpel" <bjorn.topel@gmail.com>,
"Karlsson, Magnus" <magnus.karlsson@intel.com>,
brouer@redhat.com
Subject: Re: Profiling XDP programs for performance issues
Date: Fri, 9 Apr 2021 12:10:49 +0200 [thread overview]
Message-ID: <20210409121049.18c9ea47@carbon> (raw)
In-Reply-To: <CAJ8uoz2tsbpD1OvLLThC=a8O1KNMhHqwWGG9QOUJ0MMKHnzkSg@mail.gmail.com>
On Fri, 9 Apr 2021 08:40:51 +0200
Magnus Karlsson <magnus.karlsson@gmail.com> wrote:
> On Fri, Apr 9, 2021 at 1:06 AM Neal Shukla <nshukla@riotgames.com> wrote:
> >
> > Using perf, we've confirmed that the line mentioned has a 25.58% cache miss
> > rate.
>
> Do these hit in the LLC or in DRAM? In any case, your best bet is
> likely to prefetch this into your L1/L2. In my experience, the best
> way to do this is not to use an explicit prefetch instruction but to
> touch/fetch the cache lines you need in the beginning of your
> computation and let the fetch latency and the usage of the first cache
> line hide the latencies of fetching the others. In your case, touch
> both metadata and packet at the same time. Work with the metadata and
> other things then come back to the packet data and hopefully the
> relevant part will reside in the cache or registers by now. If that
> does not work, touch packet number N+1 just before starting with
> packet N.
>
> Very general recommendations but hope it helps anyway. How exactly to
> do this efficiently is very application dependent.
I see you use driver i40e and that driver does a net_prefetch(xdp->data)
*AFTER* the XDP hook. Thus, that could explain why you are seeing this.
Can you try the patch below, and see if it solves your observed issue?
> > On Thu, Apr 8, 2021 at 2:38 PM Zvi Effron <zeffron@riotgames.com> wrote:
> > >
> > > Apologies for the spam to anyone who received my first response, but
> > > it was accidentally sent as HTML and rejected by the mailing list.
> > >
> > > On Thu, Apr 8, 2021 at 11:20 AM Neal Shukla <nshukla@riotgames.com> wrote:
> > > >
> > > > System Info:
> > > > CPU: Intel(R) Xeon(R) Gold 6150 CPU @ 2.70GHz
> > > > Network Adapter/NIC: Intel X710
> > > > Driver: i40e
> > > > Kernel version: 5.8.15
> > > > OS: Fedora 33
> > > >
> > >
> > > Slight correction, we're actually on the 5.10.10 kernel.
[PATCH] i40e: Move net_prefetch to benefit XDP
From: Jesper Dangaard Brouer <brouer@redhat.com>
DEBUG PATCH WITH XXX comments
Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
---
drivers/net/ethernet/intel/i40e/i40e_txrx.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_txrx.c b/drivers/net/ethernet/intel/i40e/i40e_txrx.c
index e398b8ac2a85..c09b8a5e6a2a 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_txrx.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_txrx.c
@@ -2121,7 +2121,7 @@ static struct sk_buff *i40e_construct_skb(struct i40e_ring *rx_ring,
struct sk_buff *skb;
/* prefetch first cache line of first page */
- net_prefetch(xdp->data);
+ net_prefetch(xdp->data); // XXX: Too late for XDP
/* Note, we get here by enabling legacy-rx via:
*
@@ -2205,7 +2205,7 @@ static struct sk_buff *i40e_build_skb(struct i40e_ring *rx_ring,
* likely have a consumer accessing first few bytes of meta
* data, and then actual data.
*/
- net_prefetch(xdp->data_meta);
+// net_prefetch(xdp->data_meta); //XXX: too late for XDP
/* build an skb around the page buffer */
skb = build_skb(xdp->data_hard_start, truesize);
@@ -2513,6 +2513,7 @@ static int i40e_clean_rx_irq(struct i40e_ring *rx_ring, int budget)
/* At larger PAGE_SIZE, frame_sz depend on len size */
xdp.frame_sz = i40e_rx_frame_truesize(rx_ring, size);
#endif
+ net_prefetch(xdp->data);
skb = i40e_run_xdp(rx_ring, &xdp);
}
@@ -2530,6 +2531,7 @@ static int i40e_clean_rx_irq(struct i40e_ring *rx_ring, int budget)
} else if (skb) {
i40e_add_rx_frag(rx_ring, rx_buffer, skb, size);
} else if (ring_uses_build_skb(rx_ring)) {
+ // XXX: net_prefetch called after i40e_run_xdp()
skb = i40e_build_skb(rx_ring, rx_buffer, &xdp);
} else {
skb = i40e_construct_skb(rx_ring, rx_buffer, &xdp);
next prev parent reply other threads:[~2021-04-09 10:13 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-08 2:19 Profiling XDP programs for performance issues Neal Shukla
2021-04-08 10:32 ` Toke Høiland-Jørgensen
2021-04-08 18:20 ` Neal Shukla
2021-04-08 21:37 ` Zvi Effron
2021-04-08 23:05 ` Neal Shukla
2021-04-09 6:40 ` Magnus Karlsson
2021-04-09 10:10 ` Jesper Dangaard Brouer [this message]
2021-04-15 1:14 ` Neal Shukla
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=20210409121049.18c9ea47@carbon \
--to=brouer@redhat.com \
--cc=bjorn.topel@gmail.com \
--cc=magnus.karlsson@gmail.com \
--cc=magnus.karlsson@intel.com \
--cc=nshukla@riotgames.com \
--cc=toke@redhat.com \
--cc=xdp-newbies@vger.kernel.org \
--cc=zeffron@riotgames.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.