netdev - Re: [PATCH v2] tcp: tsq: restore minimal amount of queueing

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: <528A3FA8.8020202@googlemail.com>
Date:	Mon, 18 Nov 2013 17:26:16 +0100
From:	Holger Hoffstätte 
	<holger.hoffstaette@...glemail.com>
To:	Francois Romieu <romieu@...zoreil.com>
CC:	netdev@...r.kernel.org
Subject: Re: [PATCH v2] tcp: tsq: restore minimal amount of queueing

On 11/18/13 00:15, Francois Romieu wrote:
> Holger Hoffstaette <holger.hoffstaette@...glemail.com> :
> [...]
>> Since I saw this with r8169->r8169 and e1000e->r8169 it's probably
>> everyone's favourite r8169 :)
>> Unfortunately I can't be more help but if you can suggest/whip up a fix
>> I'd be happy to help test.
> 
> The r8169 driver does not rely on a timer for Tx completion.

Thankx, that's good to hear.

> The patch below should not hurt.

It does not seem to hurt, but neither can I notice much of a change.
However that's probably because of some other side effects, see below.

Do I understand the diff correctly that it makes the driver perform
outstanding transmissions before budgeting reads? Just curious.

> Can you describe your system a bit more specifically ?

Server has r8169, client is either r8169 (Windows/linux) or Thinkpad
with e1000e. Clients use NFS & Samba. Since Eric's TSQ patch the erratic
3.12.0-vanilla behaviour has "stabilized" in the sense that latency &
throughout became relatively smooth and more or less as expected, both
for large copies and many small files.

However since then I found that increasing the tcp_limit_output_bytes to
262144 (twice the default of 128k) makes things really fly. Copying
large files (>1GB) over NFS from the e1000e now quickly reaches the full
1Gb line throughput. This was really surprising.

Apart from the laptop being relatively old and being difficult to
benchmark due to typical power state scaling, I suspect the e1000e
running with dynamic interrupt moderation is not completely innocent
either. I used to turn this off some years back and had great success,
but that was on Windows.

Long story short there's just too much up- and downscaling, buffering
and queueing involved in all parts to point to any single culprit, but
increasing the byte limit *has* helped everywhere and had no noticeable
impact on internet traffic. I understand the motivation for small queues
from a bufferbloat-fighting point of view (using fq_codel did wonders
for a friend without external router!), but apparently for LAN traffic
this doesn't seem to work in all cases.

Not sure if any of this is helpful. :)

cheers
Holger

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