From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pb0-f43.google.com (mail-pb0-f43.google.com [209.85.160.43]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id 773652007D3 for ; Fri, 31 Aug 2012 09:23:29 -0700 (PDT) Received: by pbbrq2 with SMTP id rq2so7133541pbb.16 for ; Fri, 31 Aug 2012 09:23:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:x-mailer:content-transfer-encoding; bh=x+6zU469zHAdk1YHv7ym+GwOqP3nggI0S/SIXISzjtk=; b=iVXs+kRjBS15g3RVOF1sHM0RJNprreP05F+caOuNmI6c6scpUvjECBM7ma4g7oV/Eg MtvalqrzR7rNwunJiSN6Ru397FlvTSajyfPXAJXCsIA3zzsJpo2Xe/U8qbMXQcc6T/+A szEKgEGWtoQAHZdY07SYQHT20MiZ5Oz9R0FRiM3fagyTtGoa+/VrRnpHWW7X9vPnv1HE hcF2zvbDKfMaW+cIan0kBAGL4dUnEpZXX9/jHQorHyOcOunCiwt4+JrJk2c3u4m3J8Mx /GdOxZ+OI+HSGdpW/D09UkKKVyMOpH49L/j7pDdBX+X8cxOaZJyXymwOxMcFR7iHFXGr eU3A== Received: by 10.66.75.168 with SMTP id d8mr16007089paw.63.1346430208954; Fri, 31 Aug 2012 09:23:28 -0700 (PDT) Received: from [10.11.14.5] ([38.96.16.75]) by mx.google.com with ESMTPS id qp6sm3724259pbc.55.2012.08.31.09.23.27 (version=SSLv3 cipher=OTHER); Fri, 31 Aug 2012 09:23:28 -0700 (PDT) From: Eric Dumazet To: Rick Jones In-Reply-To: <5040DDE9.7030507@hp.com> References: <1346396137.2586.301.camel@edumazet-glaptop> <5040DDE9.7030507@hp.com> Content-Type: text/plain; charset="UTF-8" Date: Fri, 31 Aug 2012 09:23:27 -0700 Message-ID: <1346430207.7996.11.camel@edumazet-glaptop> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Cc: codel@lists.bufferbloat.net Subject: Re: [Codel] fq_codel : interval servo X-BeenThere: codel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: CoDel AQM discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Aug 2012 16:23:29 -0000 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.