On Thu, Nov 30, 2017 at 10:55 AM, Eric Dumazet <eric.duma...@gmail.com> wrote:
> On Thu, 2017-11-30 at 09:51 -0500, Neal Cardwell wrote: > > On Thu, Nov 30, 2017 at 5:24 AM, Eric Dumazet <eric.duma...@gmail.com > > > wrote: > > > I agree that TCP itself should generate ACK smarter, on receivers > > > that > > > are lacking GRO. (TCP sends at most one ACK per GRO packets, that > > > is > > > why we did not feel an urgent need for better ACK generation) > > > > > > It is actually difficult task, because it might need an additional > > > timer, and we were reluctant adding extra complexity for that. > > > > How about just using the existing delayed ACK timer, and just making > > the delayed ACK logic a bit smarter? We could try using the existing > > logic and timers, but using something adaptive instead of the magic > > "2" MSS received to force an ACK. > > Keep in mind some distros have HZ=250 or even HZ=100 > > So even a 'one jiffie' timer could add 10ms delay. > Right, good point. I forgot about those cases. :-) neal
_______________________________________________ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
