Re: [Codel] hardware multiqueue in fq_codel?

[Jesper Dangaard Brouer <jbrouer@redhat.com>]

On Thu, 11 Jul 2013 14:18:31 -0700 Dave Taht <dave.taht@gmail.com> wrote:
> On Thu, Jul 11, 2013 at 11:54 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> > On Thu, 2013-07-11 at 11:06 -0700, Dave Taht wrote:
> >
[...]
> >>
> >> B) people that expect pfifo_fast semantics, for which substituting
> >> fq_codel behaves oddly in two ways -
[...]
> >
> > There is no 'one solution fits every needs'.
> >
> > codel is _not_ a replacement of pfifo_fast, its a replacement for
> > pfifo.

Correct: "codel" is not replacement of pfifo_fast.

But I do see "fq_codel" as a good replacement for the default qdisc
(placed on each MQ qdisc)

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).


 
> Semantically here I'm trying to "replace the default qdisc" that
> 99.98% of people use, not "replace pfifo_fast" (that 99.99% of people
> use)
> 
> or rather, come up with a strategy for doing such, one day, in some
> more easily deployable fashion.

Yes, we want to replace "the default qdisc", not discuss which qdisc
combos are semantically equivalent.  Okay, the current default is bad causing
bufferbloat, thus we want to *replace* that qdisc, and yes replacing it
will change the semantics, and that is okay as people needing the old
semantics can still change their qdisc back via tc.

-- 
Best regards,
  Jesper Dangaard Brouer
  MSc.CS, Sr. Network Kernel Developer at Red Hat
  Author of http://www.iptv-analyzer.org
  LinkedIn: http://www.linkedin.com/in/brouer