From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by huchra.bufferbloat.net (Postfix) with ESMTP id 829A021F201 for ; Fri, 12 Jul 2013 02:34:20 -0700 (PDT) Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r6C9YIa4008187 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 12 Jul 2013 05:34:18 -0400 Received: from localhost (ovpn-116-27.ams2.redhat.com [10.36.116.27]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r6C9YGlO002351; Fri, 12 Jul 2013 05:34:16 -0400 Date: Fri, 12 Jul 2013 11:34:13 +0200 From: Jesper Dangaard Brouer To: Dave Taht Message-ID: <20130712113413.4b601800@redhat.com> In-Reply-To: References: <1373564673.4600.55.camel@edumazet-glaptop> <1373568848.4600.66.camel@edumazet-glaptop> Organization: Red Hat Inc. Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25 Cc: codel@lists.bufferbloat.net Subject: Re: [Codel] hardware multiqueue in fq_codel? 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: Fri, 12 Jul 2013 09:34:20 -0000 On Thu, 11 Jul 2013 14:18:31 -0700 Dave Taht wrote: > On Thu, Jul 11, 2013 at 11:54 AM, Eric Dumazet wrote: > > On Thu, 2013-07-11 at 11:06 -0700, Dave Taht wrote: > > [...] > >> > >> B) people that expect pfifo_fast semantics, for which substituting > >> fq_codel behaves oddly in two ways - [...] > > > > There is no 'one solution fits every needs'. > > > > codel is _not_ a replacement of pfifo_fast, its a replacement for > > pfifo. Correct: "codel" is not replacement of pfifo_fast. But I do see "fq_codel" as a good replacement for the default qdisc (placed on each MQ qdisc) I also think of "fq_codel" as a good replacement for pfifo_fast. As the 3-PRIO bands in pfifo_fast is replaced with something smarter in "fq_codel". (IMHO please don't try to add a prio_fq_codel, just be because pfifo_fast had prio bands, people can just enable a prio qdisc if they really need it). > Semantically here I'm trying to "replace the default qdisc" that > 99.98% of people use, not "replace pfifo_fast" (that 99.99% of people > use) > > or rather, come up with a strategy for doing such, one day, in some > more easily deployable fashion. Yes, we want to replace "the default qdisc", not discuss which qdisc combos are semantically equivalent. Okay, the current default is bad causing bufferbloat, thus we want to *replace* that qdisc, and yes replacing it will change the semantics, and that is okay as people needing the old semantics can still change their qdisc back via tc. -- Best regards, Jesper Dangaard Brouer MSc.CS, Sr. Network Kernel Developer at Red Hat Author of http://www.iptv-analyzer.org LinkedIn: http://www.linkedin.com/in/brouer