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 <[email protected]> wrote: > On Fri, Jul 12, 2013 at 11:13 AM, Eric Dumazet <[email protected]> wrote: >> 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 because >>> 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 queues, > 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 while. > >> 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äht > > Fixing bufferbloat with cerowrt: > http://www.teklibre.com/cerowrt/subscribe.html -- Dave Täht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html _______________________________________________ Codel mailing list [email protected] https://lists.bufferbloat.net/listinfo/codel
