Re: [Codel] hardware multiqueue in fq_codel?

[Eric Dumazet <eric.dumazet@gmail.com>]

On Thu, 2013-07-11 at 14:18 -0700, Dave Taht wrote:

> I have incidentally long thought that you are also tweaking target and
> interval for your environment?

Google data centers are spread all over the world, and speed of light
was not increased by wonderful Google engineers,
thats a real pity I can tell you.


> 
> > Whole point of codel is that number of packets in the queue is
> > irrelevant. Only sojourn time is.
> 
> Which is a lovely thing in worlds with infinite amounts of memory.

The limit is a tunable, not hard-coded in qdisc, like other qdiscs.

I chose a packet count limit because pfifo was the target, and pfifo
limit is given in packets, not in bytes.

There is bfifo variant for a byte limited fifo, so feel free to add
bcodel and fq_bcodel.

Linux Qdiscs have some existing semantic.

If every new qdisc had strange and new behavior, what would happen ?

> 
> > Now if your host has memory concerns, that's a separate issue, and you
> > can adjust the qdisc limit, or add a callback from mm to be able to
> > shrink queue in case of memory pressure, if you deal with non elastic
> > flows.
> 
> So my take on this is that the default limit should be 1k on devices
> with less than 256MB of ram overall, and 10k (or more) elsewhere. This
> matches current txqueuelen behavior and has the least surprise.

What is current 'txqueuelen behavior' ?

Current 'txqueuelen behavior' is a limit of 16.000 packets on typical
10G hardware with 16 tx queues, not 1000 as you seem to believe.

If txqueuelen was a percentage of available memory, we would be in a bad
situation : With txqueuelen being 100 15 years ago, it would be 100.000
today, since ram was increased by 3 order of magnitude.

0.1 % would be too much for my laptop with 4GB of ram, and not enough
for your 256MB host.

I do not want to bloat codel/fq_codel with some strange concerns about
skb truesize resizing. No other qdisc does this, with codel/fq_codel
would be different ?

This adds a huge performance penalty and latencies. A router should
never even touch (read or write) a _single_ byte of the payload.

Whole point having a queue is to absorb bursts : You don't want to spend
cpu cycles when bursts are coming, or else there wont be bursts anymore,
but losses episodes.