Re: [Codel] hardware multiqueue in fq_codel?

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

On Mon, Jul 15, 2013 at 9:57 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Mon, 2013-07-15 at 15:40 +0200, Jesper Dangaard Brouer wrote:
>
>> Then they should also be smart enough to change their default fq_codel
>> qdisc, to be a prio band based qdisc... shouldn't they ;-)
>>
>
>
> Some companies do this classification at the edge of their network, so
> that they do not have to worry for each machine of their fleet.
>
> Forcing them to learn how to 'fix' things once a new linux version is
> installed would be quite lame. I wont be the guy responsible for this.
>
> Listen, there is no point trying to tell me how fq_codel is better than
> pfifo_fast. Is an apple better than an orange ?

Is a tesla better than a oil tanker? :)

> Instead, we only have to create a clear path.

+10!

> 1) Allow the default qdisc to be specified/chosen in Kconfig, a bit
>   like tcp congestion module (cubic is the default)

Concur. Presently that would require exposing some structures
that are private (the qdisc *ops) to this, tho... (?)

> 2) Allow the default qdisc to be selected by a /proc/sys entry, like TCP
> congestion module.

Concur.

Not clear where would be a good place there. /proc/sys/core? I am not fond
of all the tcp related stuff that ended up in ipv4...

I don't see the need for the equivalent of a tcp_allowed_congestion_control,
just a qdisc_default or default_qdisc.

> 3) Define the PRIO + codel/band0 + fq_codel/band1 + codel/band2 as a new
> standalone qdisc

Stressing "a". Concur.

> 4) Eventually switch the default Kconfig from pfifo_fast to this beast.

After tons more testing on ever wider deployments. Sure.

There's a net-next window opening up now...



-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html