[Codel] fq_codel : interval servo
eric.dumazet at gmail.com
Fri Aug 31 12:23:27 EDT 2012
On Fri, 2012-08-31 at 08:53 -0700, Rick Jones wrote:
> On 08/30/2012 11:55 PM, Eric Dumazet wrote:
> > On locally generated TCP traffic (host), we can override the 100 ms
> > interval value using the more accurate RTT estimation maintained by TCP
> > stack (tp->srtt)
> > Datacenter workload benefits using shorter feedback (say if RTT is below
> > 1 ms, we can react 100 times faster to a congestion)
> > Idea from Yuchung Cheng.
> Mileage varies of course, but what are the odds of a datacenter's
> end-system's NIC(s) being the bottleneck point? Is it worth pinging a
> couple additional cache lines around (looking at the v2 email, I'm
> ass-u-me-ing that sk_protocol and tp->srtt are on different cache lines)?
Its certainly worth pinging additional cache lines.
A host consume almost no cpu in qdisc layer (at least not in fq_codel)
A router wont use this stuff (as skb->sk will be NULL)
> If fq_codel is going to be a little bit pregnant and "layer violate" :)
> why stop at TCP?
Who said I would stop at TCP ? ;)
> Is this change rectifying an "unfairness" with the existing fq_codel and
> the 100ms for all when two TCP flows have very different srtts?
codel has to use a single interval value, and we use an average value.
It seems to work quite well.
fq_codel has the opportunity to get a per tcp flow interval value.
And this should give better behavior.
> Some perhaps overly paranoid questions:
> Does it matter that the value of tp->srtt at the time fq_codel dequeues
> will not necessarily be the same as when that segment was queued?
It matters we use the last srtt value/estimation, which is done in this
> Is there any chance of the socket going away between the time the packet
> was queued and the time it was dequeued? (Or tp->srtt becoming "undefined?")
When skb->sk is non NULL, we hold a reference to the socket, it cannot
disappear under us.
More information about the Codel