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 C456721F1BA; Mon, 3 Dec 2012 07:49:08 -0800 (PST) Received: by mail-pb0-f43.google.com with SMTP id um15so2189027pbc.16 for ; Mon, 03 Dec 2012 07:49:08 -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=LupmDqY1Lbvr4pkY1cqwh3AjjNQgg+vwtDAKJ1WItdQ=; b=w0ze/6B9ShuFbA561gKVk/xEQRk8M9RDEjy5YyRcNnLp55gmpXWBEtylt4QcK2VaKC GjbyUx9TDFyRDpduKuJDgQXqZBSuluRzmmkc+4nnfnejWelWG5vixVA2e4BqU1KV7yqv 5Pjn/hiYHbCuX80HQn7hfv4kf1MuO/nmvlFnh6c5Eupl4Vk+hu0aDoYDRTHZPuYRLm0d Ji96rOIzk8qxQZBDKtJ21DyR8qkCvWDbRrT4zfpyDsN1BLY4YD7/+Iotx2zurcx2E2Y1 F5GR2L+tkRGr2xntkobGrQnyU3rd80YrFIuFEAkpwOe4Fs//e+5bRvoHq2jEguiL2oLW bGAw== Received: by 10.68.223.131 with SMTP id qu3mr30053044pbc.89.1354549748148; Mon, 03 Dec 2012 07:49:08 -0800 (PST) Received: from [172.19.247.97] ([172.19.247.97]) by mx.google.com with ESMTPS id vo8sm8242097pbc.16.2012.12.03.07.49.06 (version=SSLv3 cipher=OTHER); Mon, 03 Dec 2012 07:49:07 -0800 (PST) From: Eric Dumazet To: paulmck@linux.vnet.ibm.com In-Reply-To: <20121203145849.GH2605@linux.vnet.ibm.com> References: <20121123221842.GD2829@linux.vnet.ibm.com> <20121128172058.GB2474@linux.vnet.ibm.com> <20121202230635.GA16359@linux.vnet.ibm.com> <87obib5qf8.fsf@toke.dk> <87fw3n5m9g.fsf@toke.dk> <20121203145849.GH2605@linux.vnet.ibm.com> Content-Type: text/plain; charset="UTF-8" Date: Mon, 03 Dec 2012 07:49:05 -0800 Message-ID: <1354549745.1388.7.camel@edumazet-glaptop> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 8bit Cc: Paolo Valente , Toke =?ISO-8859-1?Q?H=F8iland-J=F8rgensen?= , Eric Raymond , "codel@lists.bufferbloat.net" , "cerowrt-devel@lists.bufferbloat.net" , bloat , John Crispin Subject: Re: [Cerowrt-devel] [Codel] 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: Mon, 03 Dec 2012 15:49:09 -0000 On Mon, 2012-12-03 at 06:58 -0800, Paul E. McKenney wrote: > On Mon, Dec 03, 2012 at 01:54:35PM +0100, Toke Høiland-Jørgensen wrote: > > Dave Taht writes: > > > > > you have no control. The tx queue rings are flooded before control is > > > handed back to the fq_codel scheduler. You can get some control back > > > on a non-BQL driver by reducing the number of tx descriptors > > > dramatically, but that leads to issues with small vs big packets.... > > > > Right, so BQL is pretty much a requirement to get anything worthwhile > > out of fq_codel? Or is that too strongly put? > > If I understand the code correctly, without BQL, FQ-CoDel does not get > invoked at all. > > It depends on many factors. You can setup a qdisc hierarchy of on HTB/TBF and one fq_codel. Egress rate limiting is a good way to permit to build a queue in qdisc (in fq_codel) BQL in itself avoids a too large queue on the device driver, thats only a part of the problem. If your setup is a computer with 1Gbps ethernet link, and a home router with a 1Mbps upstream link that you cant access (ie install fq_codel on it), BQL on the 1Gbps link wont help in itself. It will still allow your computer to send 1Gbps worth of data that will build a huge queue on the home router. One way to handle that is using rate limiting to not create a queue on the router.