Re: [Make-wifi-fast] [Codel] fq_codel_drop vs a udp flood

[moeller0 <moeller0@gmx.de>]

Hi Eric,

> On May 6, 2016, at 17:58 , Eric Dumazet <eric.dumazet@gmail.com> wrote:
> 
> On Fri, 2016-05-06 at 17:25 +0200, moeller0 wrote:
>> Hi Eric,
>> 
>>> On May 6, 2016, at 15:25 , Eric Dumazet <eric.dumazet@gmail.com> wrote:
> 
>>> Angles of attack :
>>> 
>>> 1) I will provide a per device /sys/class/net/eth0/gro_max_frags so that
>>> we can more easily control amount of segs per GRO packets. It makes
>>> sense to have GRO, but not so much allowing it to cook big packets that
>>> might hurt FQ.
>> 
>> 	This sounds great, so we can teach, say sqm to set this to a
>> reasonable value given the (shaped) bandwidth of a given interface.
>> Would something like this also make sense/is possible on the send side
>> for GSO/TSO?
> 
> Problem of doing this on the send side, is that too big GRO packets
> would need to be segmented _before_ reaching qdisc, and we do not have
> such support. (The segmentation happens after qdisc before hitting
> device)

	Ah, so not really possible then.

> 
> In any case, that would be more cpu cycles. It is probably better to
> control GRO sizes to optimal values.

	I guess we can always limit the GRO segments on the internal ingress interfaces, so that the external egress interface never sees too “long” (as in required transmission time) aggregates/super-packets.

> 
> I posted the fq_codel patch to netdev :
> 
> https://patchwork.ozlabs.org/patch/619344/

	Saw this, to quote Stimpy “happy happy joy joy”

Best Regards
	Sebastian

> 
>