Re: [Codel] fq_codel_drop vs a udp flood

[Jesper Dangaard Brouer <brouer@redhat.com>]

On Fri, 6 May 2016 10:41:53 +0200 moeller0 <moeller0@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:
 https://github.com/torvalds/linux/blob/v4.6-rc6/net/sched/sch_fq_codel.c#L136

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(). 
 https://github.com/torvalds/linux/blob/v4.6-rc6/net/core/dev.c#L2993

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

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k