Hi Eric,
> On May 6, 2016, at 17:58 , Eric Dumazet <eric.duma...@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.duma...@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
>
>
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
