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: <1384793248.8604.72.camel@edumazet-glaptop2.roam.corp.google.com>
Date:	Mon, 18 Nov 2013 08:47:28 -0800
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Holger Hoffstätte 
	<holger.hoffstaette@...glemail.com>
Cc:	Francois Romieu <romieu@...zoreil.com>, netdev@...r.kernel.org
Subject: Re: [PATCH v2] tcp: tsq: restore minimal amount of queueing

On Mon, 2013-11-18 at 17:26 +0100, Holger Hoffstätte wrote:
> 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.

I think it would make sense to instrument the delay between the
ndo_start_xmit() and kfree_skb() for transmitted skb.

We might have a surprise for some drivers, seeing delays in the order of
several ms ....



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