[Bug 945] Transmit performance regression with NAT and 3.14

[bugzilla-daemon at netfilter.org]

https://bugzilla.netfilter.org/show_bug.cgi?id=945

Ryan Power <rpower at sysreset.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #3 from Ryan Power <rpower at sysreset.com> 2014-05-21 21:38:07 CEST ---
Please disregard this bug entry, this appeared to have been fixed in the
following patch:

http://patchwork.ozlabs.org/patch/339082/

Vlad Yasevich - April 14, 2014, 9:37 p.m.

Sometimes, when the packet arrives at skb_mac_gso_segment()
its skb->mac_len already accounts for some of the mac lenght
headers in the packet.  This seems to happen when forwarding
through and OpenSSL tunnel.

When we start looking for any vlan headers in skb_network_protocol()
we seem to ignore any of the already known mac headers and start
with an ETH_HLEN.  This results in an incorrect offset, dropped
TSO frames and general slowness of the connection.

We can start counting from the known skb->mac_len
and return at least that much if all mac level headers
are known and accounted for.

Fixes: 53d6471cef17262d3ad1c7ce8982a234244f68ec (net: Account for all vlan
headers in skb_mac_gso_segment)
CC: Eric Dumazet <eric.dumazet at gmail.com>
CC: Daniel Borkman <dborkman at redhat.com>
Tested-by: Martin Filip <nexus+kernel at smoula.net>
Signed-off-by: Vlad Yasevich <vyasevic at redhat.com>
---
 net/core/dev.c      | 2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

-- 
Configure bugmail: https://bugzilla.netfilter.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.