netdev - Re: debugging TCP stalls on high-speed wifi

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] [day] [month] [year] [list]

Message-ID: <6e1b5c34-9353-de1d-015b-68d6b20db390@gmail.com>
Date:   Mon, 16 Dec 2019 11:20:04 -0800
From:   Eric Dumazet <eric.dumazet@...il.com>
To:     Simon Barber <simon@...erduper.net>,
        Eric Dumazet <eric.dumazet@...il.com>
Cc:     Johannes Berg <johannes@...solutions.net>,
        linux-wireless@...r.kernel.org, ncardwell@...gle.com,
        netdev@...r.kernel.org, toke@...hat.com
Subject: Re: debugging TCP stalls on high-speed wifi



On 12/16/19 10:14 AM, Simon Barber wrote:
> I see Macbook wifi clients seemingly randomly switch in and out of using GRO (I’ve not yet figured out a pattern to it), and the packet rate when they are doing GRO (on a download) is much lower, due to ACKing one in 8 packets instead of every other data packet. This has a big impact on performance.
> 
> Simon
> 


GRO has been added to linux back in 2008.
LRO might have been supported on NICs even earlier.

Modern network speeds need GRO/TSO, even if this means software stacks need some changes.

If some stacks still rely on the old rule of having one ACK per two mss,
they might not have the best experience.

RFC3449 might be a good starting point.