<div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif"><span style="color:rgb(80,0,80);font-family:arial,sans-serif">On 27 January 2017 at 15:40, Eric Dumazet </span><span dir="ltr" style="color:rgb(80,0,80);font-family:arial,sans-serif"><<a href="mailto:eric.dumazet@gmail.com" target="_blank">eric.dumazet@gmail.com</a>></span><span style="color:rgb(80,0,80);font-family:arial,sans-serif"> wrote:</span><br></div><div class="gmail_quote"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div class="h5"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="m_-1718481522343432001gmail-">On Thu, 2017-01-26 at 23:55 -0800, Dave Täht wrote:<br>
><br>
> On 1/26/17 11:21 PM, Hans-Kristian Bakke wrote:<br>
> > Hi<br>
> ><br>
> > After having had some issues with inconcistent tso/gso configuration<br>
> > causing performance issues for sch_fq with pacing in one of my systems,<br>
> > I wonder if is it still recommended to disable gso/tso for interfaces<br>
> > used with fq_codel qdiscs and shaping using HTB etc.<br>
><br>
> At lower bandwidths gro can do terrible things. Say you have a 1Mbit<br>
> uplink, and IW10. (At least one device (mvneta) will synthesise 64k of<br>
> gro packets)<br>
><br>
> a single IW10 burst from one flow injects 130ms of latency.<br>
<br>
</span>That is simply a sign of something bad happening from the source.<br>
<br>
The router will spend too much time trying to fix the TCP sender by<br>
smoothing things.<br>
<br>
Lets fix the root cause, instead of making everything slow or burn mega<br>
watts.<br>
<br>
GRO aggregates trains of packets for the same flow, in sub ms window.<br>
<br>
Why ? Because GRO can not predict the future : It can not know when next<br>
interrupt might come from the device telling : here is some additional<br>
packet(s). Maybe next packet is coming in 5 seconds.<br>
<br>
Take a look at napi_poll()<br>
<br>
1) If device driver called napi_complete(), all packets are flushed<br>
(given) to upper stack. No packet will wait in GRO for additional<br>
segments.<br>
<br>
2) Under flood (we exhausted the napi budget and did not call<br>
napi_complete()), we make sure no packet can sit in GRO for more than 1<br>
ms.<br>
<br>
Only when the device is under flood and cpu can not drain fast enough RX<br>
queue, GRO can aggregate packets more aggressively, and the size of GRO<br>
packets exactly fits the CPU budget.<br>
<br>
In a nutshell, GRO is exactly the mechanism that adapts the packet sizes<br>
to available cpu power.<br>
<br>
If your cpu is really fast, then it will dequeue one packet at a time<br>
and GRO wont kick in.<br>
<br>
So the real problem here is that some device drivers implemented a poor<br>
interrupt mitigation logic, inherited from other OS that had not GRO and<br>
_had_ to implement their own crap, hurting latencies.<br>
<br>
Make sure you disable interrupt mitigation, and leave GRO enabled.<br>
<br>
e1000e is notoriously bad for interrupt mitigation.<br>
<br>
At Google, we let the NIC sends its RX interrupt ASAP.<br></blockquote><div><br></div></div></div><div><div style="font-family:verdana,sans-serif">​Interesting. Do I understand you correctly that you basically recommend ​loading the e1000e module with InterruptThrottleRate set to 0, or is interrupt mitigation something else?</div><div style="font-family:verdana,sans-serif"><br></div><div><font face="verdana, sans-serif">options e1000e InterruptThrottleRate=0(,0,0,<wbr>0...)</font><br></div><div><font face="verdana, sans-serif"><br></font></div><div><font face="verdana, sans-serif"><a href="https://www.kernel.org/doc/Documentation/networking/e1000e.txt" target="_blank">https://www.kernel.org/doc/<wbr>Documentation/networking/<wbr>e1000e.txt</a></font><br></div><div><font face="verdana, sans-serif"><br></font></div><div><font face="verdana, sans-serif">I haven't fiddled with interruptthrottlerate since before I even heard of bufferbloat.</font></div><br></div><div><div class="h5"><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Every usec matters.<br>
<br>
So the model for us is very clear : Use GRO and TSO as much as we can,<br>
but make sure the producers (TCP senders) are smart and control their<br>
burst sizes.<br>
<br>
Think about 50Gbit and 100Gbit, and really the question of having or not<br>
TSO and GRO is simply moot.<br>
<br>
<br>
Even at 1Gbit, GRO is helping to reduce cpu cycles and thus reduce<br>
latencies.<br>
<br>
Adding a sysctl to limit GRO max size would be trivial, I already<br>
mentioned that, but nobody cared enough to send a patch.<br>
<div class="m_-1718481522343432001gmail-HOEnZb"><div class="m_-1718481522343432001gmail-h5"><br>
><br>
> ><br>
> > If there is a trade off, at which bandwith does it generally make more<br>
> > sense to enable tso/gso than to have it disabled when doing HTB shaped<br>
> > fq_codel qdiscs?<br>
><br>
> I stopped caring about tuning params at > 40Mbit. < 10 gbit, or rather,<br>
> trying get below 200usec of jitter|latency. (Others care)<br>
><br>
> And: My expectation was generally that people would ignore our<br>
> recommendations on disabling offloads!<br>
><br>
> Yes, we should revise the sample sqm code and recommendations for a post<br>
> gigabit era to not bother with changing network offloads. Were you<br>
> modifying the old debloat script?<br>
><br>
> TBF & sch_Cake do peeling of gro/tso/gso back into packets, and then<br>
> interleave their scheduling, so GRO is both helpful (transiting the<br>
> stack faster) and harmless, at all bandwidths.<br>
><br>
> HTB doesn't peel. We just ripped out hsfc for sqm-scripts (too buggy),<br>
> alsp. Leaving: tbf + fq_codel, htb+fq_codel, and cake models there.<br>
><br>
<br>
<br>
<br>
> ...<br>
><br>
> Cake is coming along nicely. I'd love a test in your 2Gbit bonding<br>
> scenario, particularly in a per host fairness test, at line or shaped<br>
> rates. We recently got cake working well with nat.<br>
><br>
> <a href="http://blog.cerowrt.org/flent/steam/down_working.svg" rel="noreferrer" target="_blank">http://blog.cerowrt.org/flent/<wbr>steam/down_working.svg</a> (ignore the latency<br>
> figure, the 6 flows were to spots all over the world)<br>
><br>
> > Regards,<br>
> > Hans-Kristian<br>
> ><br>
> ><br>
> > ______________________________<wbr>_________________<br>
> > Bloat mailing list<br>
> > <a href="mailto:Bloat@lists.bufferbloat.net" target="_blank">Bloat@lists.bufferbloat.net</a><br>
> > <a href="https://lists.bufferbloat.net/listinfo/bloat" rel="noreferrer" target="_blank">https://lists.bufferbloat.net/<wbr>listinfo/bloat</a><br>
> ><br>
> ______________________________<wbr>_________________<br>
> Bloat mailing list<br>
> <a href="mailto:Bloat@lists.bufferbloat.net" target="_blank">Bloat@lists.bufferbloat.net</a><br>
> <a href="https://lists.bufferbloat.net/listinfo/bloat" rel="noreferrer" target="_blank">https://lists.bufferbloat.net/<wbr>listinfo/bloat</a><br>
<br>
<br>
______________________________<wbr>_________________<br>
Bloat mailing list<br>
<a href="mailto:Bloat@lists.bufferbloat.net" target="_blank">Bloat@lists.bufferbloat.net</a><br>
<a href="https://lists.bufferbloat.net/listinfo/bloat" rel="noreferrer" target="_blank">https://lists.bufferbloat.net/<wbr>listinfo/bloat</a><br>
</div></div></blockquote></div></div></div><br></div></div>
</div><br></div>