xdp-newbies.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jesper Dangaard Brouer <jbrouer@redhat.com>
To: Zvi Effron <zeffron@riotgames.com>, Xdp <xdp-newbies@vger.kernel.org>
Cc: brouer@redhat.com
Subject: Re: How to benchmark packet throughput for submitting patches?
Date: Mon, 8 Aug 2022 10:04:01 +0200	[thread overview]
Message-ID: <ab2802b3-6de5-1ae7-cdcb-1204e2fac8e7@redhat.com> (raw)
In-Reply-To: <CAC1LvL1E9wC8GS=x+yoAmA02iAgWRvRFu14pqHwLDzxod5RLJg@mail.gmail.com>


On 01/08/2022 23.11, Zvi Effron wrote:
> I see that many XDP patchset submissions to the bpf mailing list
> include benchmark numbers for packet throughput to show how much the
> change improves (or worsens) performance. 

It is very important to show the *change* in performance.
Meaning baseline numbers for comparison is more important than the
absolute performance numbers.

> They frequently show numbers for a single core test.
> 

The single core or actually single RX-queue test is important to XDP.
For reasons that might surprise you(?).

The intuitive reason is that it's easier to reason about and do
calculations on as we know the CPU is kept 100% busy.

The non-intuitive reason is that when scaling up with more CPUs, then
XDP is so fast that hardware becomes the bottleneck and CPUs will start
to have idle cycles.  This is MUCH harder to reason about and
understand, and is often misinterpreted.  The xdp-paper benchmarks[2]
doc examples where the HW is the bottleneck and how we identify counter
via ethtool_stats.pl [3].



> I was wondering what methodology people are using to generate these
> benchmark results?

On the packet *generator*, I usually use the kernels pktgen via the 
scripts in kernel tree under samples/pktgen/[1]

  [1] https://github.com/torvalds/linux/tree/master/samples/pktgen

  Example command:
   $ ./samples/pktgen/pktgen_sample03_burst_single_flow.sh -vi mlx5p2 -d 
10.40.40.2 -m 3c:fd:fe:b3:31:49 -t 12

As the script name "pktgen_sample03_burst_single_flow" indicate this is
generating a single flow, which will cause the RSS-hash in the NIC hit a
single RX-queue.  The '-t 12' means 12 CPU cores will be generating this
traffic.

Our xdp-paper have detailed records of the benchmarking we did:
  [2] https://github.com/xdp-project/xdp-paper/tree/master/benchmarks


On the Device Under Test (DUT) I usually run sample "xdp_rxq_info", that
report stats on a RX-queue + CPU basis.


I'm interested in hearing what other do?

--Jesper

[3] 
https://github.com/netoptimizer/network-testing/blob/master/bin/ethtool_stats.pl


      reply	other threads:[~2022-08-08  8:04 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-01 21:11 How to benchmark packet throughput for submitting patches? Zvi Effron
2022-08-08  8:04 ` Jesper Dangaard Brouer [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

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

  git send-email \
    --in-reply-to=ab2802b3-6de5-1ae7-cdcb-1204e2fac8e7@redhat.com \
    --to=jbrouer@redhat.com \
    --cc=brouer@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 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).