netdev - Re: Question about LRO/GRO and TCP acknowledgements

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: <1307986486.8149.3292.camel@tardy>
Date:	Mon, 13 Jun 2011 10:34:46 -0700
From:	Rick Jones <rick.jones2@...com>
To:	Joris van Rantwijk <joris@...isvr.nl>
Cc:	netdev@...r.kernel.org
Subject: Re: Question about LRO/GRO and TCP acknowledgements

On Sat, 2011-06-11 at 21:59 +0200, Joris van Rantwijk wrote:
> Hi,
> 
> I'm trying to understand how Linux produces TCP acknowledgements
> for segments received via LRO/GRO.
> 
> As far as I can see, the network driver uses GRO to collect several
> received packets into one big super skb, which is then handled
> during just one call to tcp_v4_rcv(). This will eventually result
> in the sending of at most one ACK packet for the entire GRO packet.
> 
> Conventional wisdom (RFC 5681) says that a receiver should send at
> least one ACK for every two data segments received. The sending TCP
> needs these ACKs to update its congestion window (e.g. slow start).
> 
> It seems to me that the current implementation in Linux may send
> just one ACK for a large number of received segments. This would
> be a deviation from the standard. As a result the congestion
> window of the sender would grow much slower than intended.
> 
> Maybe I misunderstand something in the network code (likely).
> Could someone please explain me how this ACK issue is handled?

FWIW, HP-UX and Solaris stacks (perhaps others) have had ACK-avoidance
heuristics in place since the mid to late 1990's, and the ACK-avoidance
of LRO/GRO is quite similar "on the wire."  Have those heuristics been
stellar?  Probably not, but they've not it seems caused massive
problems, and when one has TSO and LRO/GRO the overhead of
ACK-every-other-MSS processing becomes non-trivial.  Even more so when
copy-avoidance is present.

I'd go with increase by the bytes ACKed not the ACK count.

rick jones

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