[Make-wifi-fast] [Codel] fq_codel_drop vs a udp flood

[Roman Yeryomin]

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

Regards,
Roman