netdev - Re: [PATCH net-next 0/6] tcp: remove non GSO code

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <1519157377.55655.26.camel@gmail.com>
Date:   Tue, 20 Feb 2018 12:09:37 -0800
From:   Eric Dumazet <eric.dumazet@...il.com>
To:     Eric Dumazet <edumazet@...gle.com>,
        Oleksandr Natalenko <oleksandr@...alenko.name>
Cc:     "David S . Miller" <davem@...emloft.net>,
        netdev <netdev@...r.kernel.org>,
        Neal Cardwell <ncardwell@...gle.com>,
        Yuchung Cheng <ycheng@...gle.com>,
        Soheil Hassas Yeganeh <soheil@...gle.com>
Subject: Re: [PATCH net-next 0/6] tcp: remove non GSO code

On Tue, 2018-02-20 at 11:56 -0800, Eric Dumazet wrote:
> On Tue, Feb 20, 2018 at 11:51 AM, Oleksandr Natalenko
> <oleksandr@...alenko.name> wrote:
> > On úterý 20. února 2018 20:39:49 CET Eric Dumazet wrote:
> > > I am not trying to compare BBR and Reno on a lossless link.
> > > 
> > > Reno is running as fast as possible and will win when bufferbloat is
> > > not an issue.
> > > 
> > > If bufferbloat is not an issue, simply use Reno and be happy ;)
> > > 
> > > My patch helps BBR only, I thought it was obvious ;)
> > 
> > Umm, yes, and my point was rather something like "the speed on a lossless link
> > while using BBR with and without this patch is the same". Sorry for a
> > confusion. I guess, the key word here is "lossless".
> 
> That is with the other patches _not_ applied ?
> 
> Here the gain is quite big, since BBR can setup a slightly better
> cwnd, allowing proper GRO on receiver.

Also you can tune your NIC to accept few MSS per GSO/TSO packet

ip link set dev eth0 gso_max_segs 2

So even if TSO/GSO is there, BBR should not use sk->sk_gso_max_segs to
size its bursts, since burt sizes are also impacting GRO on the
receiver.