From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 55A333B25E; Fri, 6 May 2016 07:33:29 -0400 (EDT) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 8C59764449; Fri, 6 May 2016 11:33:28 +0000 (UTC) Received: from localhost (ovpn-200-47.brq.redhat.com [10.40.200.47]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u46BXOKh011337; Fri, 6 May 2016 07:33:25 -0400 Date: Fri, 6 May 2016 13:33:23 +0200 From: Jesper Dangaard Brouer To: moeller0 , Eric Dumazet Cc: brouer@redhat.com, Dave =?UTF-8?B?VMOkaHQ=?= , make-wifi-fast@lists.bufferbloat.net, ath10k , "codel@lists.bufferbloat.net" , Jonathan Morton , Roman Yeryomin Message-ID: <20160506133323.0b190f47@redhat.com> In-Reply-To: <542135C7-D7CC-4E33-B35B-C2AD259FA5AB@gmx.de> References: <865DA393-262D-40B6-A9D3-1B978CD5F6C6@gmail.com> <1462128385.5535.200.camel@edumazet-glaptop3.roam.corp.google.com> <1462136140.5535.219.camel@edumazet-glaptop3.roam.corp.google.com> <1462201620.5535.250.camel@edumazet-glaptop3.roam.corp.google.com> <1462205669.5535.254.camel@edumazet-glaptop3.roam.corp.google.com> <1462464776.13075.18.camel@edumazet-glaptop3.roam.corp.google.com> <1462476207.13075.20.camel@edumazet-glaptop3.roam.corp.google.com> <542135C7-D7CC-4E33-B35B-C2AD259FA5AB@gmx.de> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Fri, 06 May 2016 11:33:28 +0000 (UTC) Subject: Re: [Make-wifi-fast] [Codel] fq_codel_drop vs a udp flood X-BeenThere: make-wifi-fast@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2016 11:33:29 -0000 On Fri, 6 May 2016 10:41:53 +0200 moeller0 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