[Make-wifi-fast] [Codel] fq_codel_drop vs a udp flood
moeller0 at gmx.de
Fri May 6 11:25:47 EDT 2016
> On May 6, 2016, at 15:25 , Eric Dumazet <eric.dumazet at gmail.com> wrote:
> On Fri, 2016-05-06 at 13:46 +0200, moeller0 wrote:
>> Hi Jesper,
>>> On May 6, 2016, at 13:33 , Jesper Dangaard Brouer
>> <brouer at redhat.com> wrote:
>>> On Fri, 6 May 2016 10:41:53 +0200 moeller0 <moeller0 at gmx.de> wrote:
>>>> Speaking out of total ignorance, I ask why not account
>>>> GRO/GSO packets by the number of their fragments against the packet
>>>> limit? Counting a 64kB packets as equivalent to a 64B packet
>>>> is the right thing if one tries to account for the work the OS
>>>> to perform to figure out what to do with the packet, but for
>>>> the memory consumption it introduces an impressive/manly level of
>>>> uncertainty (2 orders of magnitude).
>>> Looking at the drop code in fq_codel:
>>> It looks like we are finding the "fat" flow to drop from based on
>>> number of bytes queued. And AFAIK skb->len also account for the
>>> length of all GSO packets (Eric?)
>>> Even better, we are using qdisc_pkt_len(skb), which also account for
>>> the GSO headers in qdisc_pkt_len_init().
>>> If anything, the GSO packets get hit harder by the fq_codel_drop
>>> function, as we drop the entire GSO skb.
>> This sounds all very reassuring!
>>> Is the issue you are raising that the 1024 packet limit, would allow
>>> 1024 x 64K bytes to be queued before the drop kicks in? (Resulting
>>> using too much memory on your small device).
>> Yes, I guess I need to explain better. My wndr3700v7 only sports a
>> measly 64MB ram total, so in the past with the default 10240 limit I
>> could force OOM-initiated reboots. So my angle on this issue is
>> always, I want my router to survive even if the the network is
>> over-saturated (I do not expect the router to work well under those
>> circumstances, but I somehow think it should at least not reboot
>> during DOS conditions…). Cake allows to specify a hard memory limit
>> that looks a skb-truesize to allow stricter memory control for people
>> like me, making the whole GRO/GSO issue go away, at least as far as
>> OOM is concerned. And as I begin to understand once a link reaches a
>> certain bandwidth GRO/GSO will become helpful again, especially on
>> small routers as they help reduce the work the kernel needs to to per
> 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?
> 2) Tracking skb->truesize looks mandatory for small devices.
> I will add this to fq_codel.
> 3) Making sure skb->truesize is accurate is a long term effort we want
> to constantly monitor, since some drivers are doing under estimations.
Is there an easy way to test/measure this? Say if 2) is implemented how can one figure out how much memory is actually allocated for a given queue?
Best Regards & Merci beaucoup
More information about the Make-wifi-fast