From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id D23173B25E; Fri, 6 May 2016 11:26:00 -0400 (EDT) Received: from hms-beagle.railnet.train ([88.128.81.70]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0Mcxtm-1bGv0k3auw-00IEi0; Fri, 06 May 2016 17:25:53 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: moeller0 In-Reply-To: <1462541156.13075.34.camel@edumazet-glaptop3.roam.corp.google.com> Date: Fri, 6 May 2016 17:25:47 +0200 Cc: Jesper Dangaard Brouer , =?utf-8?Q?Dave_T=C3=A4ht?= , make-wifi-fast@lists.bufferbloat.net, ath10k , "codel@lists.bufferbloat.net" , Jonathan Morton , Roman Yeryomin Content-Transfer-Encoding: quoted-printable Message-Id: <2BFC725A-F007-4D63-89BD-E1845F7E89BE@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> <20160506133323.0b190f47@redhat.com> <1462541156.13075.34.camel@edumazet-glaptop3.roam.corp.google.com> To: Eric Dumazet X-Mailer: Apple Mail (2.2104) X-Provags-ID: V03:K0:VxOrCIRHfQx+8LjBnPNUP9q38AgKsBHly8WiTNzr6/HSiq5ryC+ sx63ouILirkfeGpaFvP4+84Ws2D+whxSR0rW125uGMBO9MqPM4AeucaTO9hK+oyHDGbKTky nnkGvwR2vDyvxOhQcupFrCMl+hbtKrTA0HkOz6iydXM2oDvCv4sXTbde5speRkouwurjfRC 2hpMTjxw6DRcFzTBnWivA== X-UI-Out-Filterresults: notjunk:1;V01:K0:Gt2u+qyoqYE=:wynfqi0jfxxmsKseg27Qz3 B9POVM/MddZ3tfdL8NM56hv7jCu+T2+frbq9dyqxxSR2ASL6KktiLavTAqwT0j6L4uS70rtn8 DSZTXOqCY8FhrBrOgzCO9SX5+M4uNje1YmaFXjvunhc1HczMwPZjyXLqmxwloi/1J3D0dzcpp FfLh7av3BfCUV0kmu0SWigQM6a1X9fJQomjXOBRG8MpcjnH5aychEyzrGYCBC5pggVN3Z8AXZ Udry4ntAmcLdb4V26acvh6+BesIN4rRAlV6Q2ggwcyZxrGyE16AyHgr4GUX3153TFHIhsvuVF COWfREcfEErOnwbbv1AJVC1DksqBs2Qw4QrW21PX3BftGKJPc//JhmfmbTx420kkPLXJ4gip7 04ApNnodM/nQjzTmw0ONYl75ncWKXNxneWuv8JCiHPhF+6jej8xTQ+vJHSC6ZxksUk/2N2zeq G5KTthTv3MbB6nnfr81+Uknzl9TEAD+oQZu0COsnlbJroHqWrBgyZlqwcwyTgPIPoXEV4fgT5 Fm0d1wzorTvquvnk7wf1h2CP8TwkSi8n9E1J/0Hw2iI85kAwfucqmesismiGQ0x6XBCX5hWtY kS/Mz1DuU3WVvomzDKnqZn/jkl2Y8Ojfbavrm/JE6dfSTDBr9WsTOEbaFye/urveOfdjZ45pi TLhdkMkVbKbw24vGZTQUTMu8t0VdYFoUTwZW+4HjgeukYR8E3he452j4ZrylcfjFfjIkhEcOS IpV5W6mU4zw9d9tT6hAgT61LCugQLpueuhQEKjHZGjK5GAwQIHnxDNJQoDrLsqB0M1D0MOfd0 OdO1rm67gE3eCS/OIo/SnGKn6w+sQ== 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 15:26:01 -0000 Hi Eric, > On May 6, 2016, at 15:25 , Eric Dumazet = wrote: >=20 > On Fri, 2016-05-06 at 13:46 +0200, moeller0 wrote: >> Hi Jesper, >>=20 >>> On May 6, 2016, at 13:33 , Jesper Dangaard Brouer >> wrote: >>>=20 >>>=20 >>> On Fri, 6 May 2016 10:41:53 +0200 moeller0 wrote: >>>=20 >>>> 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).=20 >>>=20 >>> Looking at the drop code in fq_codel: >>>=20 >> = https://github.com/torvalds/linux/blob/v4.6-rc6/net/sched/sch_fq_codel.c#L= 136 >>>=20 >>> 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?) >>>=20 >>> Even better, we are using qdisc_pkt_len(skb), which also account for >>> the GSO headers in qdisc_pkt_len_init().=20 >>> https://github.com/torvalds/linux/blob/v4.6-rc6/net/core/dev.c#L2993 >>>=20 >>> If anything, the GSO packets get hit harder by the fq_codel_drop >>> function, as we drop the entire GSO skb. >>=20 >> This sounds all very reassuring! >>=20 >>>=20 >>>=20 >>> 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). >>=20 >> 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=E2=80=A6). 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 >> byte=E2=80=A6 >=20 > Angles of attack : >=20 > 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? >=20 > 2) Tracking skb->truesize looks mandatory for small devices. > I will add this to fq_codel. Thanks. >=20 > 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 Sebastian >=20 > Thanks. >=20 >=20 >=20 >=20 >=20