On Sun, 2016-05-01 at 11:26 -0700, Dave Taht wrote:
> On Sun, May 1, 2016 at 10:59 AM, Eric Dumazet wrote:
> >
> > Well, just _kill_ the offender, instead of trying to be gentle.
>
> I like it. :) Killing off a malfunctioning program flooding the local
> network interface
On Sun, 2016-05-01 at 23:35 +0300, Jonathan Morton wrote:
> > On 1 May, 2016, at 21:46, Eric Dumazet 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
> On 1 May, 2016, at 21:46, Eric Dumazet 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
On Sun, 2016-05-01 at 11:46 -0700, Eric Dumazet wrote:
> Just drop half backlog packets instead of 1, (maybe add a cap of 64
> packets to avoid too big burts of kfree_skb() which might add cpu
> spikes) and problem is gone.
>
I used following patch and it indeed solved the issue in my tests.
> On 1 May, 2016, at 20:59, Eric Dumazet wrote:
>
> fq_codel_drop() could drop _all_ packets of the fat flow, instead of a
> single one.
Unfortunately, that could have bad consequences if the “fat flow” happens to be
a TCP in slow-start on a long-RTT path. Such a flow
On Sat, 2016-04-30 at 20:41 -0700, Dave Taht wrote:
> >>>
> >>> 45.78% [kernel] [k] fq_codel_drop
> >>> 3.05% [kernel] [k] ag71xx_poll
> >>> 2.18% [kernel] [k] skb_release_data
> >>> 2.01% [kernel] [k] r4k_dma_cache_inv
>
> The udp flood behavior is
Maybe I missed something, but why is it important to optimize for a UDP flood?
A general observation of control theory is that there is almost always an
adversarial strategy that will destroy any control regime. Sometimes one has to
invoke an "oracle" that knows the state of the control system