[Codel] fq_codel_drop vs a udp flood

Jesper Dangaard Brouer brouer at redhat.com
Fri May 6 04:33:23 PDT 2016

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 probably
> is the right thing if one tries to account for the work the OS needs
> to perform to figure out what to do with the packet, but for limiting
> 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 total
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.

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 in
using too much memory on your small device).

Best regards,
  Jesper Dangaard Brouer
  MSc.CS, Principal Kernel Engineer at Red Hat
  Author of http://www.iptv-analyzer.org
  LinkedIn: http://www.linkedin.com/in/brouer

More information about the ath10k mailing list