Re: [Codel] fq_codel : interval servo

[Rick Jones <rick.jones2@hp.com>]

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)?

If fq_codel is going to be a little bit pregnant and "layer violate" :) 
why 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?

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?

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?")

rick jones