From: Alexander Duyck <alexander.h.duyck@intel.com>
To: Jesper Dangaard Brouer <brouer@redhat.com>, netdev@vger.kernel.org
Cc: Jeff Kirsher <jeffrey.t.kirsher@intel.com>,
Daniel Borkmann <dborkman@redhat.com>,
Florian Westphal <fw@strlen.de>,
"David S. Miller" <davem@davemloft.net>,
Stephen Hemminger <shemminger@vyatta.com>,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
Robert Olsson <robert@herjulf.se>,
Ben Greear <greearb@candelatech.com>,
John Fastabend <john.r.fastabend@intel.com>,
danieltt@kth.se, zhouzhouyi@gmail.com
Subject: Re: [net-next PATCH 2/5] ixgbe: increase default TX ring buffer to 1024
Date: Wed, 14 May 2014 09:28:50 -0700 [thread overview]
Message-ID: <537399C2.8070908@intel.com> (raw)
In-Reply-To: <20140514141748.20309.83121.stgit@dragon>
On 05/14/2014 07:17 AM, Jesper Dangaard Brouer wrote:
> Using pktgen I'm seeing the ixgbe driver "push-back", due TX ring
> running full. Thus, the TX ring is artificially limiting pktgen.
>
> Diagnose via "ethtool -S", look for "tx_restart_queue" or "tx_busy"
> counters.
>
> Increasing the TX ring buffer should be done carefully, as it comes at
> a higher memory cost, which can also negatively influence performance.
> E.g. ring buffer array of struct ixgbe_tx_buffer (current size 48bytes)
> increase from 512*48=24576bytes to 1024*48=49152bytes which is larger
> than the L1 data cache (32KB on my E5-2630), thus increasing the L1->L2
> cache-references.
>
> Adjusting the TX ring buffer (TXSZ) measured over 10 sec with ifpps
> (single CPU performance, ixgbe 10Gbit/s, E5-2630)
> * cmd: ethtool -G eth8 tx $TXSZ
> * 3,930,065 pps -- TXSZ= 512
> * 5,312,249 pps -- TXSZ= 768
> * 5,362,722 pps -- TXSZ=1024
> * 5,361,390 pps -- TXSZ=1536
> * 5,362,439 pps -- TXSZ=2048
> * 5,359,744 pps -- TXSZ=4096
>
> Choosing size 1024 because for the next optimizations 768 is not
> enough.
>
> Notice after commit 6f25cd47d (pktgen: fix xmit test for BQL enabled
> devices) pktgen uses netif_xmit_frozen_or_drv_stopped() and ignores
> the BQL "stack" pause (QUEUE_STATE_STACK_XOFF) flag. This allow us to put
> more pressure on the TX ring buffers.
>
> It is the ixgbe_maybe_stop_tx() call that stops the transmits, and
> pktgen respecting this in the call to netif_xmit_frozen_or_drv_stopped(txq).
>
> Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
> ---
>
> drivers/net/ethernet/intel/ixgbe/ixgbe.h | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe.h b/drivers/net/ethernet/intel/ixgbe/ixgbe.h
> index c688c8a..bf078fe 100644
> --- a/drivers/net/ethernet/intel/ixgbe/ixgbe.h
> +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe.h
> @@ -63,7 +63,7 @@
> #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
>
> /* TX/RX descriptor defines */
> -#define IXGBE_DEFAULT_TXD 512
> +#define IXGBE_DEFAULT_TXD 1024
> #define IXGBE_DEFAULT_TX_WORK 256
> #define IXGBE_MAX_TXD 4096
> #define IXGBE_MIN_TXD 64
>
What is the point of optimizing ixgbe for a synthetic benchmark? In my
experience the full stack can only handle about 2Mpps at 60B packets
with a single queue. Updating the defaults for a pktgen test seems
unrealistic as that isn't really a standard use case for the driver.
I'd say that it might be better to just add a note to the documentation
folder indicating what configuration is optimal for pktgen rather then
changing everyone's defaults to support one specific test.
Thanks,
Alex
next prev parent reply other threads:[~2014-05-14 16:28 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-14 14:17 [net-next PATCH 0/5] Optimizing "pktgen" for single CPU performance Jesper Dangaard Brouer
2014-05-14 14:17 ` [net-next PATCH 1/5] ixgbe: trivial fixes while reading code Jesper Dangaard Brouer
2014-05-14 14:17 ` [net-next PATCH 2/5] ixgbe: increase default TX ring buffer to 1024 Jesper Dangaard Brouer
2014-05-14 14:28 ` David Laight
2014-05-14 19:25 ` Jesper Dangaard Brouer
2014-05-14 16:28 ` Alexander Duyck [this message]
2014-05-14 17:49 ` David Miller
2014-05-14 19:09 ` Jesper Dangaard Brouer
2014-05-14 19:54 ` David Miller
2014-05-15 9:16 ` David Laight
2014-05-29 15:29 ` Jesper Dangaard Brouer
2014-05-14 14:17 ` [net-next PATCH 3/5] pktgen: avoid atomic_inc per packet in xmit loop Jesper Dangaard Brouer
2014-05-14 14:35 ` Eric Dumazet
2014-05-14 15:13 ` Jesper Dangaard Brouer
2014-05-14 15:35 ` Eric Dumazet
2014-05-14 14:17 ` [net-next PATCH 4/5] pktgen: avoid expensive set_current_state() call in loop Jesper Dangaard Brouer
2014-05-14 14:18 ` [net-next PATCH 5/5] pktgen: RCU'ify "if_list" to remove lock in next_to_run() Jesper Dangaard Brouer
2014-06-26 11:16 ` [net-next PATCH V2 0/3] Optimizing pktgen for single CPU performance Jesper Dangaard Brouer
2014-06-26 11:16 ` [net-next PATCH V2 1/3] pktgen: document tuning for max NIC performance Jesper Dangaard Brouer
2014-06-26 11:16 ` [net-next PATCH V2 2/3] pktgen: avoid expensive set_current_state() call in loop Jesper Dangaard Brouer
2014-06-26 11:16 ` [net-next PATCH V2 3/3] pktgen: RCU-ify "if_list" to remove lock in next_to_run() Jesper Dangaard Brouer
2014-07-01 22:51 ` [net-next PATCH V2 0/3] Optimizing pktgen for single CPU performance David Miller
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=537399C2.8070908@intel.com \
--to=alexander.h.duyck@intel.com \
--cc=brouer@redhat.com \
--cc=danieltt@kth.se \
--cc=davem@davemloft.net \
--cc=dborkman@redhat.com \
--cc=fw@strlen.de \
--cc=greearb@candelatech.com \
--cc=jeffrey.t.kirsher@intel.com \
--cc=john.r.fastabend@intel.com \
--cc=netdev@vger.kernel.org \
--cc=paulmck@linux.vnet.ibm.com \
--cc=robert@herjulf.se \
--cc=shemminger@vyatta.com \
--cc=zhouzhouyi@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 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.