netdev - Re: TCP performance regression

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]

Date:	Mon, 11 Nov 2013 17:38:24 +0100
From:	Felix Fietkau <nbd@...nwrt.org>
To:	Sujith Manoharan <sujith@...jith.org>,
	Eric Dumazet <eric.dumazet@...il.com>
CC:	netdev@...r.kernel.org, Dave Taht <dave.taht@...il.com>
Subject: Re: TCP performance regression

On 2013-11-11 17:13, Sujith Manoharan wrote:
> Eric Dumazet wrote:
>> We have many choices.
>> 
>> 1) Add back a minimum of ~128 K of outstanding bytes per TCP session,
>>    so that buggy drivers can sustain 'line rate'.
>> 
>>    Note that with 100 concurrent TCP streams, total amount of bytes
>>    queued on the NIC is 12 MB.
>>    And pfifo_fast qdisc will drop packets anyway.
>> 
>>    Thats what we call 'BufferBloat'
>> 
>> 2) Try lower values like 64K. Still bufferbloat.
>> 
>> 3) Fix buggy drivers, using a proper logic, or shorter timers (mvneta
>> case for example)
>> 
>> 4) Add a new netdev attribute, so that well behaving NIC drivers do not
>> have to artificially force TCP stack to queue too many bytes in
>> Qdisc/NIC queues.
> 
> I think the quirks of 802.11 aggregation should be taken into account.
> I am adding Felix to this thread, who would have more to say on latency/bufferbloat
> with wireless drivers.
I don't think this issue is about something as simple as timer handling
for tx completion (or even broken/buggy drivers).

There's simply no way to make 802.11 aggregation work well and have
similar tx completion latency characteristics as Ethernet devices.

802.11 aggregation reduces the per-packet airtime overhead by combining
multiple packets into one transmission (saving a lot of time getting a
tx opportunity, transmitting the PHY header, etc.), which makes the
'line rate' heavily depend on the amount of buffering.

Aggregating multiple packets into one transmission also causes extra
packet loss, which is compensated by retransmission and reordering, thus
introducing additional latency.

I don't think that TSQ can do a decent job of mitigating bufferbloat on
802.11n devices without a significant performance hit, so adding a new
netdev attribute might be a good idea.

- Felix
--
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