From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ww0-f47.google.com (mail-ww0-f47.google.com [74.125.82.47]) (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 DA54F200B1B for ; Wed, 2 Nov 2011 04:31:27 -0700 (PDT) Received: by wwf22 with SMTP id 22so60719wwf.28 for ; Wed, 02 Nov 2011 04:31:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type; bh=OjP8AKUYJBdiEamqlssum37giAcLO2RqfOXC9OY5TrU=; b=XKGYYTP+w31Qz/XDgnghK+2iXqbwstZt2SW9EnbLjBVyabqVo1plfgcxhxM0iv0ntg uqce2GYzkV9alBPSn2ZsF8/LnDLrC87h7s76B3ubfMHlsRYwBMReBdKmiPgmYcGTAAFj wgDBLJpWsz0CqgekuRh51RtiU0CPM1OaPDVR8= Received: by 10.227.197.81 with SMTP id ej17mr4982877wbb.13.1320233485917; Wed, 02 Nov 2011 04:31:25 -0700 (PDT) Received: from [172.30.42.102] (gob75-7-82-247-114-230.fbx.proxad.net. [82.247.114.230]) by mx.google.com with ESMTPS id es5sm3624152wbb.11.2011.11.02.04.31.24 (version=SSLv3 cipher=OTHER); Wed, 02 Nov 2011 04:31:24 -0700 (PDT) Message-ID: <4EB12A0A.3010602@gmail.com> Date: Wed, 02 Nov 2011 12:31:22 +0100 From: =?UTF-8?B?RGF2aWQgVMOkaHQ=?= Organization: Bufferbloat.net User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Eric Dumazet References: <1319716772.2601.26.camel@edumazet-laptop> <1319731732.2601.40.camel@edumazet-laptop> <1319732832.2601.43.camel@edumazet-laptop> <4EB115F7.5070203@gmail.com> <1320229869.2292.5.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC> In-Reply-To: <1320229869.2292.5.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC> Content-Type: multipart/mixed; boundary="------------090108080902090602060606" Cc: netdev@vger.kernel.org, Karel Rericha , bloat Subject: Re: [Bloat] Quick Fair Queue scheduler maturity and examples X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 11:31:28 -0000 This is a multi-part message in MIME format. --------------090108080902090602060606 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 11/02/2011 11:31 AM, Eric Dumazet wrote: > Le mercredi 02 novembre 2011 à 11:05 +0100, David Täht a écrit : >> (Example elided, see thread on netdev) >> >> On 11/02/2011 10:36 AM, Karel Rericha wrote: >>> 2011/10/27 Eric Dumazet: >>> Thanks for example Eric. But it only added more confusion to me now >>> :-) I was under impression (and read somewhere) that QFQ is non work >>> conserving scheduler so I can use it more or less like HTB or HFSC to >>> set bandwidth constraints to flows. But from this example (and from >>> sources/patches/papers I try not to pretend I fully understand) it >>> looks to me like some multiqueue scheduler with arbitrary number of >>> queues and ability to arbitrary assign flows to this queues. So some >>> sort of fair division of available bandwidth to flows without >>> arbitrary bandwidth caps to these flows. >> This is what I want! It may not be what you want... >>> I really dont see what is non work conserving here :-S Please save my >>> soul and enlighten me because I am at dead end now :-) >> I initially had great hope for QFQ as I've been saying (mostly >> privately) that "PFIFO_FAST must die" for over a year now. What to >> replace it with is a rather large question, but I felt a start would be >> to adopt some FQ algorithm. Over the last couple weeks I read all the >> papers regarding DRR and QFQ and also poked into the source code and >> like you, am seriously un-enlightened. >> >> I think eric's example is misleading as he divided up the queues by >> bandwidth, rather than flow, in the first tier of his tc hierarchy. >> useful as a test... > It seems there is a bit of misunderstanding here. > > QFQ is not a 'all is included' in one qdisc, like SFQ I grok. (or rather, I did after some reading last week) > > You really need to setup qfq classes, and describe how packets are > mapped to qfq classes (this is done by an external flow classifier) It would be mildly better (in the case of wireless) to be able to do flow classification based on the nexthop mac, which while introducing an extra routing table lookup, would improve packet aggregation probabilities in the multiple ip or multi-hop wireless case. I don't know if a route lookup of dest mac could be correctly done at this layer. > It also has no internal (default) flow classifier like SFQ did. > > It has of course no bandwidth constraints. If you need to shape and use > QFQ, you'll have to use QFQ + a shaping qdisc. (This is why I used HTB > in my script because I wanted to shape) I just want FQ... for now. > If you dont need to shape, you still need to describe/setup qfq classes > and chose appropriate flow classifier. > Trying for two levels of flow classification here, which I still doubt I can do here... hmm, perhaps with ifb... don't want to shape, want to ultimately apply some level of a post-RED AQM to the overall flows > -- Dave Täht --------------090108080902090602060606 Content-Type: text/x-vcard; charset=utf-8; name="dave_taht.vcf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="dave_taht.vcf" YmVnaW46dmNhcmQNCmZuO3F1b3RlZC1wcmludGFibGU6RGF2ZSBUPUMzPUE0aHQNCm47cXVv dGVkLXByaW50YWJsZTpUPUMzPUE0aHQ7RGF2ZQ0KZW1haWw7aW50ZXJuZXQ6ZGF2ZS50YWh0 QGdtYWlsLmNvbQ0KdGVsO2hvbWU6MS0yMzktODI5LTU2MDgNCnRlbDtjZWxsOjA2Mzg2NDUz NzQNCngtbW96aWxsYS1odG1sOkZBTFNFDQp2ZXJzaW9uOjIuMQ0KZW5kOnZjYXJkDQoNCg== --------------090108080902090602060606--