[Codel] hardware multiqueue in fq_codel?

[Dave Taht]

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