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 CN "smtp.gmail.com", Issuer "Google Internet Authority" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 7D882200619; Sun, 2 Dec 2012 13:47:43 -0800 (PST) Received: by mail-pb0-f43.google.com with SMTP id um15so1621897pbc.16 for ; Sun, 02 Dec 2012 13:47:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=43PeQAYob50WmoLDOzWH//GxE1NQ08w9TLYT00tdPuU=; b=J6A8aL/0Qu3bydy/66qBuxzPsQ9nDUtNRVIwRyZai2gpXJsTmVheT22nQH/dGv2QU9 t34+hHVgXcTc1VBPpQ5tjJdLdvvEcL1UX8zXwcs6Dtdwg/zd1bv+zbI7ezXgeGHAbY7G YKOvHIi3Ka+rBN0R1Ey08GjIJfsu8xfuoDLOMyblX1oB9ofSKRXwd91dd0vIK5QJYYB3 TmhyeFaC8II9IVUhCZw5XNDmYa1LdV8Egbxg9ol0lCsDIkm/GICIvhMbvdqjRrxUPCVD bgTzbgP6nEjCtPBafma9Kd5lzrDTDzO5x5tW5MHapZKInx6ZeRJvSN/4hTDPPG3cFclK a76g== Received: by 10.66.81.198 with SMTP id c6mr20880948pay.50.1354484862866; Sun, 02 Dec 2012 13:47:42 -0800 (PST) Received: from ?IPv6:2406:e000:63ed:1:c1c7:a457:f080:90b6? ([2406:e000:63ed:1:c1c7:a457:f080:90b6]) by mx.google.com with ESMTPS id gv9sm6845911pbc.21.2012.12.02.13.47.36 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 02 Dec 2012 13:47:39 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Andrew McGregor In-Reply-To: <87vcckb0el.fsf@toke.dk> Date: Mon, 3 Dec 2012 10:47:29 +1300 Content-Transfer-Encoding: quoted-printable Message-Id: <344628E4-C813-4410-AB39-57C7081021B6@gmail.com> References: <20121127224915.GM2474@linux.vnet.ibm.com> <20121128002710.GS2474@linux.vnet.ibm.com> <50B5887C.7010605@pollere.com> <20121128043838.GX2474@linux.vnet.ibm.com> <20121128160133.GA16995@linux.vnet.ibm.com> <20121128174440.GD2474@linux.vnet.ibm.com> <1354129222.14302.508.camel@edumazet-glaptop> <87vcckb0el.fsf@toke.dk> To: =?iso-8859-1?Q?Toke_H=F8iland-J=F8rgensen?= X-Mailer: Apple Mail (2.1499) Cc: Paolo Valente , Eric Dumazet , "codel@lists.bufferbloat.net" , "cerowrt-devel@lists.bufferbloat.net" , bloat , paulmck@linux.vnet.ibm.com, John Crispin Subject: Re: [Cerowrt-devel] [Codel] [Bloat] FQ_Codel lwn draft article review X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Dec 2012 21:47:44 -0000 On 3/12/2012, at 10:37 AM, Toke H=F8iland-J=F8rgensen = wrote: > Eric Dumazet writes: >=20 >> This can help if you really want to avoid a thick flow sharing a thin >> flow bucket, but given that all packets are going eventually into the >> Internet (or equivalent crowded network), its not really a clear win. >=20 > I've been trying to grok the fq_codel code by reading through it while > following the discussion in the article, and I'm having a bit of = trouble > squaring the thin/thick (or "hog"/"non-hog") flow designation of the > article with the code. As far as I can tell from the code, there are = two > lists, called new_flows and old_flows; and a flow starts out as 'new' > and stays that way until it has sent a quantum of bytes or codel fails > to dequeue a packet from it, whereupon it is moved to the end of the > old_flows list. It then stays in the old_flows list for the rest of = its > "life". 'new' is what I was calling 'thin', and 'old' is the 'thick' list. When a flow drains, it disappears from both lists (but is not garbage = collected), and will come back on the 'new' or 'thin' list. The code = for this is in enqueue, where if the flow is not on either list it gets = put on the tail of the 'new' list. >=20 > Now, talking about thin flows being distinguished from thick ones, it > seems to me that if a flow sends packets at a low enough rate it can = in > principle stay 'thin' indefinitely. So I'm assuming I've missed > something in the code that allows a flow to stay in the new_flows list > if it is sufficiently thin. Could someone please point out to me what > I'm missing? :) It's the implicit return to the 'new' list. >=20 > Thanks, >=20 > -Toke >=20 > --=20 > Toke H=F8iland-J=F8rgensen > toke@toke.dk > _______________________________________________ > Codel mailing list > Codel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/codel