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

[Eric Dumazet]

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/