From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) (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 4197A200628 for ; Mon, 15 Jul 2013 10:19:02 -0700 (PDT) Received: by mail-ie0-f178.google.com with SMTP id u16so25834161iet.23 for ; Mon, 15 Jul 2013 10:19:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=0VWyhx1mtDJkY9KgnznXTnI+yyRlCLcFwZbtTgfurC8=; b=Dxq5NLukP8f3YAwU55Q3PXUE1dcy55IYS3fSlkQq5gvpvsWdHbrRtJE0vvgrocnf1N 6sRRaHgtwGntusoFzyEoqDCwZ4XFSC5Zq8CDjv6W1LgXlEnyT4FO/2Oq3ujzraZbew/T qGljXTxTZQYpS0HBRO3jfxItolPVE1AxXdT7qTAxV7nO9gSqUsvLl4d/vVXYzy+lfwQi BQ2eSmef+FXAm9+h6BXLDVwMU4GP8Dwuhgql7NbTKfKUn83b3GcaJ//P7aMi0BpBIw4y ZQuufQ7L3O+3PaAC8jNa5JuWbZMGdTr05oJcTsdR2h4O3YRrqO+i9t6QCkpDduMmfJs2 qkxg== MIME-Version: 1.0 X-Received: by 10.50.65.99 with SMTP id w3mr7627991igs.37.1373908741372; Mon, 15 Jul 2013 10:19:01 -0700 (PDT) Received: by 10.64.98.162 with HTTP; Mon, 15 Jul 2013 10:19:00 -0700 (PDT) In-Reply-To: <1373896674.10804.73.camel@edumazet-glaptop> References: <1373564673.4600.55.camel@edumazet-glaptop> <1373568848.4600.66.camel@edumazet-glaptop> <20130712113413.4b601800@redhat.com> <1373642001.10804.18.camel@edumazet-glaptop> <1373648057.10804.29.camel@edumazet-glaptop> <20130715154009.4c0d4531@redhat.com> <1373896674.10804.73.camel@edumazet-glaptop> Date: Mon, 15 Jul 2013 13:19:00 -0400 Message-ID: From: Dave Taht To: Eric Dumazet Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: codel@lists.bufferbloat.net, Jesper Dangaard Brouer 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: Mon, 15 Jul 2013 17:19:02 -0000 On Mon, Jul 15, 2013 at 9:57 AM, Eric Dumazet wrot= e: > On Mon, 2013-07-15 at 15:40 +0200, Jesper Dangaard Brouer wrote: > >> Then they should also be smart enough to change their default fq_codel >> qdisc, to be a prio band based qdisc... shouldn't they ;-) >> > > > Some companies do this classification at the edge of their network, so > that they do not have to worry for each machine of their fleet. > > Forcing them to learn how to 'fix' things once a new linux version is > installed would be quite lame. I wont be the guy responsible for this. > > Listen, there is no point trying to tell me how fq_codel is better than > pfifo_fast. Is an apple better than an orange ? Is a tesla better than a oil tanker? :) > Instead, we only have to create a clear path. +10! > 1) Allow the default qdisc to be specified/chosen in Kconfig, a bit > like tcp congestion module (cubic is the default) Concur. Presently that would require exposing some structures that are private (the qdisc *ops) to this, tho... (?) > 2) Allow the default qdisc to be selected by a /proc/sys entry, like TCP > congestion module. Concur. Not clear where would be a good place there. /proc/sys/core? I am not fond of all the tcp related stuff that ended up in ipv4... I don't see the need for the equivalent of a tcp_allowed_congestion_control= , just a qdisc_default or default_qdisc. > 3) Define the PRIO + codel/band0 + fq_codel/band1 + codel/band2 as a new > standalone qdisc Stressing "a". Concur. > 4) Eventually switch the default Kconfig from pfifo_fast to this beast. After tons more testing on ever wider deployments. Sure. There's a net-next window opening up now... --=20 Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.= html