[Codel] fq_codel_drop vs a udp flood

Roman Yeryomin leroi.lists at gmail.com
Mon May 2 07:18:34 PDT 2016

On 1 May 2016 at 23:55, Eric Dumazet <eric.dumazet at gmail.com> wrote:
> On Sun, 2016-05-01 at 23:35 +0300, Jonathan Morton wrote:
>> > On 1 May, 2016, at 21:46, Eric Dumazet <eric.dumazet at gmail.com> wrote:
>> >
>> > Optimizing the search function is not possible, unless you slow down the
>> > fast path. This was my design choice.
>> I beg to differ.  Cake iterates over the queues in the bulk and sparse
>> lists, rather than all queues full stop.  That’s a straightforward
>> optimisation which covers the case in question here, and has no effect
>> on the fast path.
> Thats not going to help, sorry, if you have hundreds of flows in these
> queues. (I had 200 TCP_STREAM running in my test, plus one hostile
> It is going to be _much_ slower, since you'll bring in cpu caches way
> more memory, while disc spinlock is held.
> Better have a known cost of 1 cache line miss per drop, instead of 200
> cache line misses per drop.
> (4096 bytes to store q->backlogs[] array -> 64 cache lines.
> If we drop 64 skb per pass, this averages to 1 cache line miss per drop)
> Listen, I never thought people were going to use fq_codel in some
> hostile env.
> I simply designed it to be used in home routers, so I would not imagine
> someone would be trying to kill its own Internet connection.

Imagine you are a video operator, have MacBook Pro, gigabit LAN and
NAS on ethernet side. You would want to get maximum speed. And
fq_codel just dropped it down to 550Mbps for TCP (instead of 750Mbps)
and to 30Mbps for UDP (instead of 900Mbps).
So, again, it looks broken to me.


More information about the ath10k mailing list