From: vyasevich@gmail.com
To: netdev@vger.kernel.org
Cc: Vladislav Yasevich <vyasevic@redhat.com>,
Jeff Kirsher <jeffrey.t.kirsher@intel.com>,
Jesse Brandeburg <jesse.brandeburg@intel.com>,
Bruce Allan <bruce.w.allan@intel.com>,
Carolyn Wyborny <carolyn.wyborny@intel.com>,
Don Skidmore <donald.c.skidmore@intel.com>,
Greg Rose <gregory.v.rose@intel.com>,
Alex Duyck <alexander.h.duyck@intel.com>,
John Ronciak <john.ronciak@intel.com>,
Mitch Williams <mitch.a.williams@intel.com>,
Linux NICS <linux.nics@intel.com>,
e1000-devel@lists.sourceforge.net,
Rasesh Mody <rmody@brocade.com>,
Thadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com>,
Thomas Petazzoni <thomas.petazzoni@free-electrons.com>,
Shahed Shaikh <shahed.shaikh@qlogic.com>,
Jitendra Kalsaria <jitendra.kalsaria@qlogic.com>,
Ron Mercer <ron.mercer@qlogic.com>,
linux-driver@qlogic.com, Chris Metcalf <cmetcalf@tilera.com>
Subject: [PATCH 0/8] Fix TSO and checksum issues with non-accelerated vlan traffic.
Date: Fri, 22 Aug 2014 22:17:02 -0400 [thread overview]
Message-ID: <1408760230-7457-1-git-send-email-vysevich@gmail.com> (raw)
From: Vladislav Yasevich <vyasevic@redhat.com>
I've recently ran across something rather interesting when testing vlans
from inside VMs. In some scenarios I was getting awfull thruput.
Some debugging uncovered a very scary packet corruption. I was
seeing packets that had original TSO length as IP total length
and their ip checksum was 0. This was with e1000e driver.
A bit more debugging uncovered an assumption made by that driver
that skb->protocol will contain l3 protocol information. This
was not the case in my setup since I manually turned off vlan
tx acceleration for the device. This caused the driver to not
initialize the tso information correctly and resulted in
corrupt TSO frames on the wire.
I decided to do some auditing of the usage of skb->protocols
in the drivers. Out of all the drivers, the included 8 appear
to be effected. They all allow user to control vlan acceleration
settings, all support TSO on vlan devices, and all use
skb->protocol to decide how to encode TSO information. Some
also have similar problems when initializing hw checksum information.
On such device, it is simple enough to reproduce the issue.
Simply turn off TX VLAN acceleration on the device, create a vlan,
and run you favorite network performance tool.
There is 1 driver I ran across that I belive will trigger a BUG
in the system when used with vlans. That driver is tile/tilepro.c
I have not changed it in this patch set and would hope that
the maintainer has time to look at it.
Thanks
-vlad
Vladislav Yasevich (8):
e1000e: Fix TSO with non-accelerated vlans
e1000: Fix TSO for non-accelerated vlan traffic
bna: Support TSO and partial checksum with non-accelerated vlans.
ehea: Fix TSO and hw checksums with non-accelerated vlan packets.
i40e: Fix TSO and hw checksums for non-accelerated vlan packets.
i40evf: Fix TSO and hw checksums for non-accelerated vlan packets.
mvneta: Fix TSO and checksum for non-acceleration vlan traffic
qlge: Fix TSO for non-accelerated vlan traffic
drivers/net/ethernet/brocade/bna/bnad.c | 7 ++++---
drivers/net/ethernet/ibm/ehea/ehea_main.c | 2 +-
drivers/net/ethernet/intel/e1000/e1000_main.c | 19 +++++++++++--------
drivers/net/ethernet/intel/e1000e/netdev.c | 21 +++++++++------------
drivers/net/ethernet/intel/i40e/i40e_txrx.c | 2 +-
drivers/net/ethernet/intel/i40evf/i40e_txrx.c | 2 +-
drivers/net/ethernet/marvell/mvneta.c | 7 ++++---
drivers/net/ethernet/qlogic/qlge/qlge_main.c | 5 +++--
8 files changed, 34 insertions(+), 31 deletions(-)
--
1.9.3
next reply other threads:[~2014-08-23 2:17 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-23 2:17 vyasevich [this message]
2014-08-23 2:17 ` [PATCH 1/8] e1000e: Fix TSO with non-accelerated vlans vyasevich
2014-08-23 2:17 ` [PATCH 2/8] e1000: Fix TSO for non-accelerated vlan traffic vyasevich
2014-08-23 2:17 ` [PATCH 3/8] bna: Support TSO and partial checksum with non-accelerated vlans vyasevich
2014-08-23 2:17 ` [PATCH 4/8] ehea: Fix TSO and hw checksums with non-accelerated vlan packets vyasevich
2014-08-23 2:17 ` [PATCH 5/8] i40e: Fix TSO and hw checksums for " vyasevich
2014-08-23 18:43 ` David Miller
2014-08-24 1:13 ` Vlad Yasevich
2014-08-23 2:17 ` [PATCH 6/8] i40evf: " vyasevich
2014-08-23 2:17 ` [PATCH 7/8] mvneta: Fix TSO and checksum for non-acceleration vlan traffic vyasevich
2014-08-23 2:17 ` [PATCH 8/8] qlge: Fix TSO for non-accelerated " vyasevich
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=1408760230-7457-1-git-send-email-vysevich@gmail.com \
--to=vyasevich@gmail.com \
--cc=alexander.h.duyck@intel.com \
--cc=bruce.w.allan@intel.com \
--cc=carolyn.wyborny@intel.com \
--cc=cascardo@linux.vnet.ibm.com \
--cc=cmetcalf@tilera.com \
--cc=donald.c.skidmore@intel.com \
--cc=e1000-devel@lists.sourceforge.net \
--cc=gregory.v.rose@intel.com \
--cc=jeffrey.t.kirsher@intel.com \
--cc=jesse.brandeburg@intel.com \
--cc=jitendra.kalsaria@qlogic.com \
--cc=john.ronciak@intel.com \
--cc=linux-driver@qlogic.com \
--cc=linux.nics@intel.com \
--cc=mitch.a.williams@intel.com \
--cc=netdev@vger.kernel.org \
--cc=rmody@brocade.com \
--cc=ron.mercer@qlogic.com \
--cc=shahed.shaikh@qlogic.com \
--cc=thomas.petazzoni@free-electrons.com \
--cc=vyasevic@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).