i40e: ignore skb->xmit_more when deciding to set RS bit
authorJacob Keller <jacob.e.keller@intel.com>
Tue, 29 Aug 2017 09:32:42 +0000 (05:32 -0400)
committerJeff Kirsher <jeffrey.t.kirsher@intel.com>
Fri, 6 Oct 2017 15:11:32 +0000 (08:11 -0700)
commita5340d933e3cd7829a24bacc156dd1e475a1ae2c
treeefaf663628170a4cb16edf3f3dae457a39a8df1c
parent0a3b4f702fb1f76b03530d58af9efc5e10392185
i40e: ignore skb->xmit_more when deciding to set RS bit

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