netdev - Re: tcp: Do not apply TSO segment limit to non-TSO packets

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1420223040.32621.6.camel@edumazet-glaptop2.roam.corp.google.com>
Date:	Fri, 02 Jan 2015 10:24:00 -0800
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Herbert Xu <herbert@...dor.apana.org.au>
Cc:	Thomas Jarosch <thomas.jarosch@...ra2net.com>,
	netdev@...r.kernel.org, edumazet@...gle.com,
	Steffen Klassert <steffen.klassert@...unet.com>,
	Ben Hutchings <bhutchings@...arflare.com>,
	"David S. Miller" <davem@...emloft.net>
Subject: Re: tcp: Do not apply TSO segment limit to non-TSO packets

On Thu, 2015-01-01 at 00:42 +1100, Herbert Xu wrote:
> On Thu, Jan 01, 2015 at 12:39:23AM +1100, Herbert Xu wrote:
> >
> > Thomas Jarosch reported IPsec TCP stalls when a PMTU event occurs.
> > 
> > In fact the problem was completely unrelated to IPsec.  The bug is
> > also reproducible if you just disable TSO/GSO.
> 
> This raises two interesting questions.
> 
> Firstly not many people test non-TSO code paths anymore so bugs
> are likely to persist for a long time there.  Perhaps it's time
> to remove the non-TSO code path altogether? The GSO code path
> should provide enough speed-up in terms of boosting the effective
> MTU to offset the cost of copying.

> Secondly why are we dealing with hardware TSO segment limits
> by limiting the size of the TSO packet in the TCP stack? Surely
> in this case GSO is free since there won't be any copying?

It might depends on the device capabilities.

Non TSO/GSO path is known to be better for devices unable to perform TX
checksumming, as we compute the checksum at the time we copy data from
user to kernel (csum_and_copy_from_user() from tcp_sendmsg())).

With BQL+TSQ, having to compute the TX hash means bringing data into cpu
caches a second time right before ndo_start_xmit()

But maybe this gain is very relative in a full blown configuration, with
netfilter / complex qdisc being used.

Thanks Herbert !


--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html