<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 30, 2017 at 10:55 AM, Eric Dumazet <span dir="ltr"><<a href="mailto:eric.dumazet@gmail.com" target="_blank">eric.dumazet@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Thu, 2017-11-30 at 09:51 -0500, Neal Cardwell wrote:<br>
> On Thu, Nov 30, 2017 at 5:24 AM, Eric Dumazet <<a href="mailto:eric.dumazet@gmail.com">eric.dumazet@gmail.com</a><br>
> > wrote:<br>
> > I agree that TCP itself should generate ACK smarter, on receivers<br>
> > that<br>
> > are lacking GRO. (TCP sends at most one ACK per GRO packets, that<br>
> > is<br>
> > why we did not feel an urgent need for better ACK generation)<br>
> ><br>
> > It is actually difficult task, because it might need an additional<br>
> > timer, and we were reluctant adding extra complexity for that.<br>
><br>
> How about just using the existing delayed ACK timer, and just making<br>
> the delayed ACK logic a bit smarter? We could try using the existing<br>
> logic and timers, but using something adaptive instead of the magic<br>
> "2" MSS received to force an ACK.<br>
<br>
</span>Keep in mind some distros have HZ=250 or even HZ=100<br>
<br>
So even a 'one jiffie' timer could add 10ms delay.<br></blockquote><div><br></div><div>Right, good point. I forgot about those cases. :-)</div><div><br></div><div>neal</div><div><br></div><div><br></div></div></div></div>