Re: [Codel] hardware multiqueue in fq_codel?

[Dave Taht <dave.taht@gmail.com>]

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 <dave.taht@gmail.com> wrote:
> On Fri, Jul 12, 2013 at 11:13 AM, Eric Dumazet <eric.dumazet@gmail.com> 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