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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1307890657.2872.158.camel@edumazet-laptop>
Date:	Sun, 12 Jun 2011 16:57:37 +0200
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Joris van Rantwijk <joris@...isvr.nl>
Cc:	netdev@...r.kernel.org
Subject: Re: Question about LRO/GRO and TCP acknowledgements

Le dimanche 12 juin 2011 à 13:24 +0200, Joris van Rantwijk a écrit :
> On 2011-06-12, Eric Dumazet <eric.dumazet@...il.com> wrote:
> > So your concern is more a Sender side implementation missing this
> > recommendation, not GRO per se...
> 
> Not really. The same RFC says:
>   Specifically, an ACK SHOULD be generated for at least every
>   second full-sized segment, ...
> 

Well, SHOULD is not MUST.


> I can see how the world may have been a better place if every sender
> implemented Appropriate Byte Counting and TCP receivers were allowed to
> send fewer ACKs. However, current reality is that ABC is optional,
> disabled by default in Linux, and receivers are recommended to send one
> ACK per two segments.
> 

ABC might be nice for stacks that use byte counters for cwnd. We use
segments.

> I suspect that GRO currently hurts throughput of isolated TCP
> connections. This is based on a purely theoretic argument. I may be
> wrong and I have absolutely no data to confirm my suspicion.
> 
> If you can point out the flaw in my reasoning, I would be greatly
> relieved. Until then, I remain concerned that there may be something
> wrong with GRO and TCP ACKs.

Think of GRO being a receiver facility against stress/load, typically in
datacenter.

Only when receiver is overloaded, GRO kicks in and can coalesce several
frames before being handled in TCP stack in one run.

If receiver is so loaded that more than 2 frames are coalesced in a NAPI
run, it certainly helps to not allow sender to increase its cwnd more
than one SMSS. We probably are right before packet drops anyway.



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