Re: [Codel] fq_codel_drop vs a udp flood

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

On Sun, 2016-05-01 at 23:35 +0300, Jonathan Morton wrote:
> > On 1 May, 2016, at 21:46, Eric Dumazet <eric.dumazet@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.



_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k