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
_______________________________________________
Codel mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/codel
