From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) (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 D005A21F181 for ; Fri, 12 Jul 2013 09:39:20 -0700 (PDT) Received: by mail-ie0-f181.google.com with SMTP id x12so21281667ief.12 for ; Fri, 12 Jul 2013 09:39:20 -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=+huj/AH6vEtvJvYgbIhMs2yaSHW8Kdadvzh6//tX5Jo=; b=bV6HDmjPAozG2z8GUnLs7ok2UusN3XRfKa/3Z9dUaBmOsXyJ1mHzegXAaFVjw6blPO RDOHNVulPmCDG1UaxLedak76KJAgCS04/JLe4XVTRJrNcAS9GmVzYFg8COQKPPgarbXE xDSnWR2SxBl2GXfDpNXDlSnnO2jdhFKQtmrZyUe8u7drf3Wt1d+Bz6tjkFCEpnL4dK5h xkeI+BNb78IrAAW9FExJu+zRp7n7yByvhbzPqqBapLFAbevzXTrdZkoXbAazscdSGJAY qiTQ0UF58lXnexURBfPL+e7p/F4jcrC1UDFM0T58z4RYxM7yFFYcC0dgPYbWtfIATNpj PGaA== MIME-Version: 1.0 X-Received: by 10.50.3.103 with SMTP id b7mr1155305igb.54.1373647160159; Fri, 12 Jul 2013 09:39:20 -0700 (PDT) Received: by 10.64.98.162 with HTTP; Fri, 12 Jul 2013 09:39:20 -0700 (PDT) In-Reply-To: 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:39:20 -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:39:21 -0000 aghh, er, this message was riddled with off-by-one errors. In the first part of the message I started from 0, then I started to start from 1... My coffee machine broke this morning. On Fri, Jul 12, 2013 at 12:37 PM, Dave Taht wrote: > On Fri, Jul 12, 2013 at 11:13 AM, Eric Dumazet w= rote: >> 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 beca= use >>> 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 queu= es > will need to vastly exceed the packet limit rather than the number of que= ues, > thus yielding the same behavior as a normal attack against pfifo_fast, an= d > 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 w= hile. > >> 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. > >> >> >> > > > > -- > Dave T=E4ht > > Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscrib= e.html --=20 Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.= html