From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) (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 05AE321F1B1 for ; Fri, 12 Jul 2013 09:37:22 -0700 (PDT) Received: by mail-ie0-f179.google.com with SMTP id c10so20164720ieb.24 for ; Fri, 12 Jul 2013 09:37:22 -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=XQiu8mo0Nb6Lesva8DpnQaDISt5fcqQo/b9x/+8deHk=; b=0/2wVO7ykHpF4jLtYyNDbx/KBItEcUaOe/eQG5gGxbZrcj9+hwGR7QKaJTOuHk9XlQ Y059NWf7taKkM5nQuC2uC0y5ZVU26Ozq48j7UxVc5P4BkWDzPDBwyzCuIoxqSRkg6HMO Py04pzZH1SwXgERiWjAy3jv1dr2nQixtSu7Ca12NvvDxONoQCKlSS3D9JNaeZ25WKnr+ BUWWjBAo8vWDy2hAydGss9mOq/zyeVGQzeC92vLG3ec6SS9BeZRC4eGMos8gnB2bbTv1 OQhuaZZvTWy+ZQjws2cBuKjX/ic0RREVplGPlnixjSJzgR+TzLAy+E2bIKEbtsQfY/Hv wb7Q== MIME-Version: 1.0 X-Received: by 10.42.37.203 with SMTP id z11mr12918994icd.56.1373647042441; Fri, 12 Jul 2013 09:37:22 -0700 (PDT) Received: by 10.64.98.162 with HTTP; Fri, 12 Jul 2013 09:37:22 -0700 (PDT) In-Reply-To: <1373642001.10804.18.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> Date: Fri, 12 Jul 2013 12:37:22 -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: Fri, 12 Jul 2013 16:37:23 -0000 On Fri, Jul 12, 2013 at 11:13 AM, Eric Dumazet wro= te: > On Fri, 2013-07-12 at 11:34 +0200, Jesper Dangaard Brouer wrote: > >> 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 becau= se >> pfifo_fast had prio bands, people can just enable a prio qdisc if they >> really need it). > > Nope. Its really easy for an attacker to flood your fq_codel with say > UDP messages on all available hash slots. This is not strictly true, as the hash is permuted by a secret random number, any level of dumb attack as an attempt to fill all available queues will need to vastly exceed the packet limit rather than the number of queue= s, thus yielding the same behavior as a normal attack against pfifo_fast, and in the general case an attack that would overwhelm pfifo_fast won't be anywhere near as damaging against fq_codel. While it is possible to determine the permutation value it would take a whi= le. > Some people really want the high prio packets to be sent before any > med/low prio packets. Not everybody uses a separate ethernet port for > management and heartbeats. I agree this is a strong argument for a strictly priority queue to exist, but would prefer it codeled. Don't mind it fq_codeled either... > If we want to replace pfifo_fast as the default qdisc, we want some > integrated qdisc with 3 bands. Agree. > I presume something really simple like : > > a fifo for band 0 messages > a fq_codel for band 1 messages > a fifo for band 2 messages > > Would be more than enough, and this also should use device txqueue len > as the (dynamic) limit, because some existing scripts expect to control > qdisc limit using "ifconfig eth0 txqueuelen 100", not a tc script. I believe this would suffice! although I continue to argue for fq_codel on band 2 with a very limited number of queues by default (say, 8), and some level of service guarantee better than starvation. txqueuelen 100 is rather low for codel queue, so I wouldn't mind if the lowest value was capped at say, 600, but informed by the txqueuelen setting to do so. in one version of cake I'd merely taken out some queues for 1 and 3 out of the flows array, changed the hash to account for the offsets using band2prio on the skb->priority field, converted the new_flows and old_flows pointers to a flows[4]. I got stuck on trying to provide some service guarantee for all three queues. (well, I was trying at the time to do weights or more than three queues, too) Gave up and misplaced the work. So I've come around to where I can live with a strict priority queue, a la pfifo_fast, that can starve the other queues, and should come with a large red warning label if used. This simplifies providing a service guarantee to an integer value, say, a default of 10 (so service is provided every 10th attempt at delivery from queue 2), to the 3rd queue. > > > --=20 Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.= html