Merge branch 'tso_fix'
authorDavid S. Miller <davem@davemloft.net>
Tue, 26 Aug 2014 00:27:47 +0000 (17:27 -0700)
committerDavid S. Miller <davem@davemloft.net>
Tue, 26 Aug 2014 00:27:47 +0000 (17:27 -0700)
commit8dbb200fa4589174202a131bd6dc45b7d569df96
treefe056ca032ee9d8b0307b4502e198f0efc3a2209
parent2b7890e757bc42f963c835521c2657bd16d7b7d6
parent1ee1cfe7d3df00bff11dd28576eeac1875d7d51f
Merge branch 'tso_fix'

Vladislav Yasevich says:

====================
Fix TSO and checksum issues with non-accelerated vlan traffic.

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.

V2: Fix i40ev using the wrong function name.  Full build.
====================

Signed-off-by: David S. Miller <davem@davemloft.net>