[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1432686994.4060.312.camel@edumazet-glaptop2.roam.corp.google.com>
Date: Tue, 26 May 2015 17:36:34 -0700
From: Eric Dumazet <eric.dumazet@...il.com>
To: Herbert Xu <herbert@...dor.apana.org.au>
Cc: davem@...emloft.net, netdev@...r.kernel.org, ncardwell@...gle.com
Subject: Re: [PATCH net-next] tcp: tcp_tso_autosize() minimum is one packet
On Wed, 2015-05-27 at 08:03 +0800, Herbert Xu wrote:
> Eric Dumazet <eric.dumazet@...il.com> wrote:
> >
> > - if (tso_segs == 1 || !max_segs) {
> > + if (tso_segs == 1) {
>
> What we're testing for here with max_segs is actually the question
> "is TSO enabled". So with your patch we will be taking the TSO
> code path even when TSO is disabled. Now this may or may not
> trigger the original bug that I was trying to fix but it still
> feels unsafe.
>
> So please convince me that it is totally safe to take the TSO
> code path with TSO disabled, e.g., when PMTU causes tso_segs
> to be greater than one.
tldr: "TSO with max_segs==1" <is the same than> "no TSO/GSO"
So worth thing that will happen is that the call to
tcp_mss_split_point() / tso_fragment() will nicely split the (TSO/GSO)
packet in a nice non GSO packet of one MSS before transmit.
Right now, one can "ethtool -K eth0 tso off gso off" in the middle of a
TCP session and tcp_write_xmit() automatically falls back to splitting
too big skbs that were cooked at the time GSO/TSO was considered true in
sendmsg().
Not sure what you need to be convinced ;)
Thanks !
--
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
Powered by blists - more mailing lists