<div dir="ltr"><div style>To begin with, I tend to use the term 'flow queuing' to distinguish what we're doing with classic "fair queuing", which is overbound in most people's minds, and some of what we do is "unfair" by some metrics.</div>
<div><br></div>Secondly, an extremely important factoid about why we got so excited about fq_codel (which is really DRR, in term derived from SFQ, combined with CoDel along with detecting thin vs. thick flows) is its performance:<br>
<br>If my memory serves me correctly, Eric Dumazet has bench marked fq_codel, when running on a modern x86 processor with modern NIC's only takes a few percent of one x86 core at a 10gE rate.  And we get higher total bandwidth over the link as a result.  Eric, please correct me if I'm wrong, but you did say I could quote you!<br>
<br>Similarly, Dave Taht reports when using fq_codel on CeroWrt (a 600mhz MIPS commodity home router), while the cost of running the fq_codel algorithm is visible in the performance traces, it's well down the list of what functions in Linux are taking the CPU time on that architecture, with huge latency benefits.<br>
<br>As a result, at the last Linux Plumber's Conference in August, there was general consensus that we could replace PFIFO_FAST as the default qdisc in Linux, awaiting just our confidence that fq_codel (or something very similar) was mature enough for such a step.<br>
<br>These two results demonstrated that on current general purpose architectures, an algorithm such as fq_codel is really do-able for the edge of the Internet.  <div><br></div><div>That is not the same statement as saying you can turn on existing implementations of various other fair queuing algorithms in existing big routers or not; just that on general purpose processors we know we can do with these algorithms immediately.<br>
<br>I think we all need to reset our expectations from the 1990's where we took away the impression that SFQ/DRR etc were too expensive for deployment: today's general purpose systems are very different than those we had in that era, now often dominated by cache misses more than anything else.  Everything we think we know about performance needs to be revisited in the light of modern architectures.</div>
<div>             Best regards,<br>                    - JIm</div></div>