From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
To: davem@davemloft.net
Cc: Jacob Keller <jacob.e.keller@intel.com>,
netdev@vger.kernel.org, nhorman@redhat.com, sassmann@redhat.com,
jogreene@redhat.com, Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Subject: [net-next 14/15] i40e: ignore skb->xmit_more when deciding to set RS bit
Date: Fri, 6 Oct 2017 10:57:26 -0700 [thread overview]
Message-ID: <20171006175727.868-15-jeffrey.t.kirsher@intel.com> (raw)
In-Reply-To: <20171006175727.868-1-jeffrey.t.kirsher@intel.com>
From: Jacob Keller <jacob.e.keller@intel.com>
Since commit 6a7fded776a7 ("i40e: Fix RS bit update in Tx path and
disable force WB workaround") we've tried to "optimize" setting the
RS bit based around skb->xmit_more. This same logic was refactored
in commit 1dc8b538795f ("i40e: Reorder logic for coalescing RS bits"),
but ultimately was not functionally changed.
Using skb->xmit_more in this way is incorrect, because in certain
circumstances we may see a large number of skbs in sequence with
xmit_more set. This leads to a performance loss as the hardware does not
writeback anything for those packets, which delays the time it takes for
us to respond to the stack transmit requests. This significantly impacts
UDP performance, especially when layered with multiple devices, such as
bonding, VLANs, and vnet setups.
This was not noticed until now because it is difficult to create a setup
which reproduces the issue. It was discovered in a UDP_STREAM test in
a VM, connected using a vnet device to a bridge, which is connected to
a bonded pair of X710 ports in active-backup mode with a VLAN. These
layered devices seem to compound the number of skbs transmitted at once
by the qdisc. Additionally, the problem can be masked by reducing the
ITR value.
Since the original commit does not provide strong justification for this
RS bit "optimization", revert to the previous behavior of setting the RS
bit every 4th packet.
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/ethernet/intel/i40e/i40e_txrx.c | 34 ++++-------------------------
1 file changed, 4 insertions(+), 30 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_txrx.c b/drivers/net/ethernet/intel/i40e/i40e_txrx.c
index d9fdf69bbc6e..3bd176606c09 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_txrx.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_txrx.c
@@ -3167,38 +3167,12 @@ static inline int i40e_tx_map(struct i40e_ring *tx_ring, struct sk_buff *skb,
/* write last descriptor with EOP bit */
td_cmd |= I40E_TX_DESC_CMD_EOP;
- /* We can OR these values together as they both are checked against
- * 4 below and at this point desc_count will be used as a boolean value
- * after this if/else block.
+ /* We OR these values together to check both against 4 (WB_STRIDE)
+ * below. This is safe since we don't re-use desc_count afterwards.
*/
desc_count |= ++tx_ring->packet_stride;
- /* Algorithm to optimize tail and RS bit setting:
- * if queue is stopped
- * mark RS bit
- * reset packet counter
- * else if xmit_more is supported and is true
- * advance packet counter to 4
- * reset desc_count to 0
- *
- * if desc_count >= 4
- * mark RS bit
- * reset packet counter
- * if desc_count > 0
- * update tail
- *
- * Note: If there are less than 4 descriptors
- * pending and interrupts were disabled the service task will
- * trigger a force WB.
- */
- if (netif_xmit_stopped(txring_txq(tx_ring))) {
- goto do_rs;
- } else if (skb->xmit_more) {
- /* set stride to arm on next packet and reset desc_count */
- tx_ring->packet_stride = WB_STRIDE;
- desc_count = 0;
- } else if (desc_count >= WB_STRIDE) {
-do_rs:
+ if (desc_count >= WB_STRIDE) {
/* write last descriptor with RS bit set */
td_cmd |= I40E_TX_DESC_CMD_RS;
tx_ring->packet_stride = 0;
@@ -3219,7 +3193,7 @@ static inline int i40e_tx_map(struct i40e_ring *tx_ring, struct sk_buff *skb,
first->next_to_watch = tx_desc;
/* notify HW of packet */
- if (desc_count) {
+ if (netif_xmit_stopped(txring_txq(tx_ring)) || !skb->xmit_more) {
writel(i, tx_ring->tail);
/* we need this if more than one processor can write to our tail
--
2.14.2
next prev parent reply other threads:[~2017-10-06 17:57 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-06 17:57 [net-next 00/15][pull request] 40GbE Intel Wired LAN Driver Updates 2017-10-06 Jeff Kirsher
2017-10-06 17:57 ` [net-next 01/15] i40e: fix a typo in i40e_pf documentation Jeff Kirsher
2017-10-06 17:57 ` [net-next 02/15] i40e: add private flag to control source pruning Jeff Kirsher
2017-10-06 17:57 ` [net-next 03/15] i40e/i40evf: spread CPU affinity hints across online CPUs only Jeff Kirsher
2017-10-06 17:57 ` [net-next 04/15] i40e: re-enable PTP L4 capabilities for XL710 if FW >6.0 Jeff Kirsher
2017-10-06 17:57 ` [net-next 05/15] i40e: redfine I40E_PHY_TYPE_MAX Jeff Kirsher
2017-10-06 17:57 ` [net-next 06/15] i40e: fix incorrect register definition Jeff Kirsher
2017-10-06 17:57 ` [net-next 07/15] i40e/i40evf: use DECLARE_BITMAP for state Jeff Kirsher
2017-10-06 17:57 ` [net-next 08/15] i40e: fix merge error Jeff Kirsher
2017-10-06 17:57 ` [net-next 09/15] i40e: Display error message if module does not meet thermal requirements Jeff Kirsher
2017-10-06 17:57 ` [net-next 10/15] i40e: Properly maintain flow director filters list Jeff Kirsher
2017-10-06 17:57 ` [net-next 11/15] i40e: implement split PCI error reset handler Jeff Kirsher
2017-10-06 17:57 ` [net-next 12/15] i40e: do not enter PHY debug mode while setting LEDs behaviour Jeff Kirsher
2017-10-06 17:57 ` [net-next 13/15] i40evf: enable support for VF VLAN tag stripping control Jeff Kirsher
2017-10-06 17:57 ` Jeff Kirsher [this message]
2017-10-09 9:07 ` [net-next 14/15] i40e: ignore skb->xmit_more when deciding to set RS bit David Laight
2017-10-09 16:28 ` Alexander Duyck
2017-10-09 20:10 ` Keller, Jacob E
2017-10-06 17:57 ` [net-next 15/15] i40e/i40evf: organize and re-number feature flags Jeff Kirsher
2017-10-06 22:41 ` [net-next 00/15][pull request] 40GbE Intel Wired LAN Driver Updates 2017-10-06 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=20171006175727.868-15-jeffrey.t.kirsher@intel.com \
--to=jeffrey.t.kirsher@intel.com \
--cc=davem@davemloft.net \
--cc=jacob.e.keller@intel.com \
--cc=jogreene@redhat.com \
--cc=netdev@vger.kernel.org \
--cc=nhorman@redhat.com \
--cc=sassmann@redhat.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).