On Thu, Dec 12, 2019 at 5:46 PM Eric Dumazet <eric.dumazet@xxxxxxxxx> wrote: > > > > On 12/12/19 4:59 PM, Simon Barber wrote: > > I’m currently adding ACK thinning to Linux’s GRO code. Quite a simple addition given the way that code works. > > > > Simon > > > > > > Please don't. > > 1) It will not help since many NIC do not use GRO. > > 2) This does not help if you receive one ACK per NIC interrupt, which is quite common. Packets accumulate in the wifi device and driver, if that's the bottleneck. > > 3) This breaks GRO transparency. > > 4) TCP can implement this in a more effective/controlled way, > since the peer know a lot more flow characteristics. > > Middle-box should not try to make TCP better, they usually break things. I generally have more hope for open source attempts at this than other means. And there isn't much left in TCP that will change in the future; it is an ossified protocol. 802.11n, at least, has a problem fitting many packets into an aggregate. Sending less packets is a win in multiple ways: A) Improves bi-directional throughput B) Reduces the size of the receivers txop (and retries) - the client is also often running at a lower rate than the ap. C) Delivers the most current ack, sooner When further transiting an aqm that uses random numbers, it hits the right packet sooner, also. I welcome experimentation in this area. -- Make Music, Not War Dave Täht CTO, TekLibre, LLC http://www.teklibre.com Tel: 1-831-435-0729
