From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.tohojo.dk (mail.tohojo.dk [188.40.53.186]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id 51363208AAD; Mon, 3 Dec 2012 07:19:47 -0800 (PST) Received: from alrua-laptop.borgediget.toke.dk (unknown [172.16.1.4]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.tohojo.dk (Postfix) with ESMTPSA id DB8071EC0CCA; Mon, 3 Dec 2012 16:19:44 +0100 (CET) Received: by alrua-laptop.borgediget.toke.dk (Postfix, from userid 1000) id 20372897; Mon, 3 Dec 2012 16:19:44 +0100 (CET) From: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= To: paulmck@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> Date: Mon, 03 Dec 2012 16:19:41 +0100 In-Reply-To: <20121203145849.GH2605@linux.vnet.ibm.com> (Paul E. McKenney's message of "Mon, 3 Dec 2012 06:58:49 -0800") Message-ID: <8738zn5fjm.fsf@toke.dk> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.2 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Cc: Paolo Valente , Eric Raymond , "codel@lists.bufferbloat.net" , "cerowrt-devel@lists.bufferbloat.net" , bloat , John Crispin Subject: Re: [Codel] [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: Mon, 03 Dec 2012 15:19:47 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable "Paul E. McKenney" writes: > If I understand the code correctly, without BQL, FQ-CoDel does not get > invoked at all. But doesn't fq_codel live at the qdisc layer? How can BQL determine whether or not fq_codel gets invoked? Or does "invoked" mean something different in this context? I can understand how this happens *effectively* by fq_codel just dequeuing packets at once into the device buffers, thus rendering the whole exercise moot. Either way, perhaps spelling this out in the article would be a good idea so people don't start experimenting with fq_codel and conclude it doesn't work, when the culprit is really missing BQL support in their driver? I know that it technically says that now, but perhaps a more prominent mention might be prudent? :) =2DToke =2D-=20 Toke H=C3=B8iland-J=C3=B8rgensen toke@toke.dk --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iQEcBAEBCAAGBQJQvMMNAAoJEENeEGz1+utPd9gIAJ6xmg2m05yvBKdHWfdvK7Jv u3UBfI/Rx4pKqa2FVBVQoJAeujJbbKAgDaDpeIgiaiIoivY/yIocqGbsCJO3h4s8 MGMZF/0gE8I6tVQF4TRyQi2cfto/kEN5GyXGX/MBOk9v3TWfQm4FZimSkoe6DNE3 wNmUAc4a0g2CvUKf41H1nvtSsNW1eh7Y+nXVbGdQjGun5+CY6kIlOw3BuZMv45Wn kaXPAJQUDL/1PDbTQkvulYWLfq5IchrBMPcjEyI0kNx9yIo/PaOf/jQGnVZPhK3+ 1Gb9Cz9FCB+xMXnGgzr+j0od2/4ziFm8+s0wvr+GMtE8bSPAE6ONXGXNGJjzBdM= =GwZX -----END PGP SIGNATURE----- --=-=-=--