On Sun, May 1, 2016 at 10:59 AM, Eric Dumazet <[email protected]> wrote: > 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 not "weird". The test is wrong. It is so filling >> the local queue as to dramatically exceed the bandwidth on the link. > > Well, just _kill_ the offender, instead of trying to be gentle.
I like it. :) Killing off a malfunctioning program flooding the local network interface (intentionally or unintentionally) seems like a useful idea. it will break some test tools that deserve to be broken, too. > fq_codel_drop() could drop _all_ packets of the fat flow, instead of a > single one. > > It is too cpu intensive to be kind to the elephant, since under pressure > fq_codel_drop() needs to be called for every enqueue. A somewhat gentler approach might be drop 3 packets or more per fq_codel_drop round - or "nearly" the entire flow (all but the last packet). But sure, dropping *all* of an unresponsive elephant (as more will be arriving), in the event of the extreme overload that hitting fq_codel_drop represents, sounds pretty good. > Really, we should not try to let inelastic flows hurt us. +10. > > I can provide a patch. Killing the bad program, and dropping all of the fattest flow strike me as two patches.[1] This approach is akin to some of the thoughts in here: https://tools.ietf.org/html/draft-ietf-tsvwg-circuit-breaker-14 [2] ... all that said, is there any way to exert flow control on a udp socket from down in these layers? [1] what sort of error code should a program killed for flooding the network return? [2] I don't actually agree with some of the thinking in the circuit breakers doc, but.... this is something of an outgrowth of the obsolete and wrong source quench idea, which might be useful history for someone: https://tools.ietf.org/html/rfc6633. -- Dave Täht Let's go make home routers and wifi faster! With better software! http://blog.cerowrt.org _______________________________________________ Codel mailing list [email protected] https://lists.bufferbloat.net/listinfo/codel
