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