Re: 3.14 regression: huge latency in read/select on tun

From: Eric Dumazet
Date: Sun Apr 20 2014 - 12:31:46 EST


On Sat, 2014-04-19 at 22:13 +0200, Ortwin GlÃck wrote:
> On 03.04.2014 15:50, Eric Dumazet wrote:
> > On Thu, 2014-04-03 at 06:19 -0700, Eric Dumazet wrote:
> >
> >> It seems TSO support is broken.
>
> I finally found time to bisect this:
>
> 53d6471cef17262d3ad1c7ce8982a234244f68ec is the first bad commit
> commit 53d6471cef17262d3ad1c7ce8982a234244f68ec
> Author: Vlad Yasevich <vyasevic@xxxxxxxxxx>
> Date: Thu Mar 27 17:26:18 2014 -0400
>
> net: Account for all vlan headers in skb_mac_gso_segment
>
> skb_network_protocol() already accounts for multiple vlan
> headers that may be present in the skb. However, skb_mac_gso_segment()
> doesn't know anything about it and assumes that skb->mac_len
> is set correctly to skip all mac headers. That may not
> always be the case. If we are simply forwarding the packet (via
> bridge or macvtap), all vlan headers may not be accounted for.
>
> A simple solution is to allow skb_network_protocol to return
> the vlan depth it has calculated. This way skb_mac_gso_segment
> will correctly skip all mac headers.
>
> Signed-off-by: Vlad Yasevich <vyasevic@xxxxxxxxxx>
> Signed-off-by: David S. Miller <davem@xxxxxxxxxxxxx>
>
> :040000 040000 6066ee76dd70dde2f4675155579e550d29ba0216
> 2196ebff4f9a8b909617dd57beeaa76cbafc8525 M include
> :040000 040000 20fdfb5efc1ada562b7899d0d58998914b1c2ff1
> c398988f31e1b1b6ee56cb20b1a7becbdf782a17 M net
> --


Hmm.. probably already solved by commit
1e785f48d29a09b6cf96db7b49b6320dada332e1
("net: Start with correct mac_len in skb_network_protocol")


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/