Re: [Codel] fq_codel : interval servo

[Eric Dumazet <eric.dumazet@gmail.com>]

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
patch.

> 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.