From: David S. Miller Date: Tue, 26 Aug 2014 00:27:47 +0000 (-0700) Subject: Merge branch 'tso_fix' X-Git-Tag: firefly_0821_release~176^2~3268^2~44 X-Git-Url: http://demsky.eecs.uci.edu/git/?a=commitdiff_plain;h=8dbb200fa4589174202a131bd6dc45b7d569df96;p=firefly-linux-kernel-4.4.55.git 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 --- 8dbb200fa4589174202a131bd6dc45b7d569df96