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: <1391787297.10160.50.camel@edumazet-glaptop2.roam.corp.google.com>
Date:	Fri, 07 Feb 2014 07:34:57 -0800
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	John Ogness <john.ogness@...utronix.de>
Cc:	netdev@...r.kernel.org
Subject: Re: nonagle flags for TSQ

On Fri, 2014-02-07 at 16:08 +0100, John Ogness wrote:
> Hi,
> 
> This email is referring to your Linux patch
> 46d3ceabd8d98ed0ad10f20c595ca784e34786c5.
> 
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=46d3ceabd8d98ed0ad10f20c595ca784e34786c5
> 
> I have a question about the use of tcp_write_xmit() in
> net/ipv4/tcp_output.c
> 
> When tcp_write_xmit() is called, the nonagle flag of the tcp socket is
> ignored and instead 0 is passed. This causes the Nagle-algorithm to be
> used even if it should not be, which in some cases causes a large delay.
> 
> Was there a reason that 0 was hard-coded?
> 
> Although current mainline code has been refactored, 0 is still
> hard-coded for TSQ cases.

Hi John

Do you have any data, like exact kernel version you use, tcpdump or
things like that ?

When the TCP writes are throttled, its only up to the point next packet
is TX completed, and only if you have at least 128KB worth of bytes
consumed in the QDISC/NIC layers for this socket.

We had some issues at very high speeds, not related to Nagle at all.

98e09386c0ef tcp: tsq: restore minimal amount of queueing
c9eeec26e32e tcp: TSQ can use a dynamic limit
d6a4a1041176 tcp: GSO should be TSQ friendly
d01cb20711e3 tcp: add LAST_ACK as a valid state for TSQ

I am not aware of TSQ being a problem for Nagle.

Also take a look at recent TCP autocork patches, as they are more
related to Nagle

a181ceb501b3 tcp: autocork should not hold first packet in write queue
f54b311142a9 tcp: auto corking

Thanks


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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ