On Fri, 6 May 2016 10:41:53 +0200 moeller0 <moell...@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
