On Mon, Jul 15, 2013 at 9:57 AM, Eric Dumazet <[email protected]> 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 _______________________________________________ Codel mailing list [email protected] https://lists.bufferbloat.net/listinfo/codel
