From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vb0-f43.google.com (mail-vb0-f43.google.com [209.85.212.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 6D3F621F174; Sun, 2 Dec 2012 14:30:15 -0800 (PST) Received: by mail-vb0-f43.google.com with SMTP id fs19so1401383vbb.16 for ; Sun, 02 Dec 2012 14:30:14 -0800 (PST) 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=FU4VwxJGuK3a5rt3HGGw/y3M5bDmk+sCvt28AL+fIz8=; b=vF8ZIJms2f5Tprb+yRNxplNpsgc5otUulooxK7eUTkOL8TnzPuycMtbygrdgLcSqyz 6IAEMHhGEz5vi8OpXwLHLXz4biSZ8O/TpG1fMMWX6VdP/OJv7TPAJ5HmnX15QE1XBVpl 7hyy7zaW3TmDhjYdV8j/IiFTOKHv1g54pJV8wGzhgqFoATtLg8K2kX+5UiDkLRLKtdj5 IdEDnz8qlFbv6zQnkH1sWr4j5DbT/ep+h4DE2Uq3fhomVxXs01BUhkBPqHPclTSllPJc OZ4MXcXTCQWvkWc4I5dRm8/Xb6hAan6DU8tIY7ew3FX4ptqZtLvvkw0TjP3XB4SfOUSN m3xw== Received: by 10.52.176.6 with SMTP id ce6mr6145694vdc.57.1354487414320; Sun, 02 Dec 2012 14:30:14 -0800 (PST) Received: from [172.26.38.113] ([172.26.38.113]) by mx.google.com with ESMTPS id dq8sm4861318vdc.4.2012.12.02.14.30.11 (version=SSLv3 cipher=OTHER); Sun, 02 Dec 2012 14:30:13 -0800 (PST) From: Eric Dumazet To: Toke =?ISO-8859-1?Q?H=F8iland-J=F8rgensen?= In-Reply-To: <87lidgaynn.fsf@toke.dk> 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> <1354486069.20109.1206.camel@edumazet-glaptop> <87lidgaynn.fsf@toke.dk> Content-Type: text/plain; charset="UTF-8" Date: Sun, 02 Dec 2012 14:30:09 -0800 Message-ID: <1354487409.20109.1235.camel@edumazet-glaptop> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 8bit Cc: Paolo Valente , "codel@lists.bufferbloat.net" , "cerowrt-devel@lists.bufferbloat.net" , bloat , paulmck@linux.vnet.ibm.com, John Crispin Subject: Re: [Codel] [Bloat] [Cerowrt-devel] FQ_Codel lwn draft article review 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: Sun, 02 Dec 2012 22:30:16 -0000 On Sun, 2012-12-02 at 23:15 +0100, Toke Høiland-Jørgensen wrote: > Eric Dumazet writes: > > > If the next packet arrives while the bucket is still in old_flows, > > we wont put the bucket in new_flow, its bucket have to wait its turn in > > the RR list. > > Right. So in order to stay in the new_flows list, the flow needs to be > slow enough that no new data is added to it in the time it takes > subsequent dequeue invocations to get back to it in the old_flows list? I guess so. It must travel through the old_flows list from the tail to the head (so each flows in old_flows must be serviced by one quantum), to get the right to be declared as 'empty' and gain the honor to get promoted to 'new_flows' next time a packet is enqueued. If all flows are slow, but the queue can still build up, because there are too many flows for the possible bandwidth, than all flows are actually considered as thick, as if we had a single RR queue. (the old_flows).