[Codel] fq_codel_drop vs a udp flood
Eric Dumazet
eric.dumazet at gmail.com
Sun May 1 16:55:40 EDT 2016
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.
So I believe I will sent this patch as is to David Miller for inclusion.
More information about the Codel
mailing list