[Codel] fq_codel_drop vs a udp flood

Eric Dumazet eric.dumazet at gmail.com
Sun May 1 11:46:25 PDT 2016


On Sun, 2016-05-01 at 21:20 +0300, Jonathan Morton wrote:
> > On 1 May, 2016, at 20:59, Eric Dumazet <eric.dumazet at gmail.com> 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 is
> responsive, but on an order-magnitude longer timescale than may have
> been configured as optimum.

Are you trying to reinvent Hystart ? ;)
> 
> The real problem is that fq_codel_drop() performs the same (excessive)
> amount of work to cope with a single unresponsive flow as it would for
> a true DDoS.  Optimising the search function is sufficient.

Optimizing the search function is not possible, unless you slow down the
fast path. This was my design choice.

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.

TCP in slow start wont be hurt at all. A fat TCP flow is still fat.

Only bad CC could possibly be hurt.






More information about the ath10k mailing list