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 21C733B25E; Fri, 6 May 2016 07:46:36 -0400 (EDT) Received: from [172.17.3.79] ([134.76.241.253]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MI5rO-1avu7N2ysQ-003scF; Fri, 06 May 2016 13:46:23 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: moeller0 In-Reply-To: <20160506133323.0b190f47@redhat.com> Date: Fri, 6 May 2016 13:46:21 +0200 Cc: Eric Dumazet , =?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: 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> To: Jesper Dangaard Brouer X-Mailer: Apple Mail (2.2104) X-Provags-ID: V03:K0:BYxNWFTWANqJA3212W2RnQMkvNmA1yESoS7B2NETGTFhhH1J/KU cFkHlnCxpLL9w2soTWleISk0dDSvphzAqlBqpodpp1MV+PPkUCMzYPRBZCil1OT6Ql1Aerr Yp1vXbbB6u3C2Vd4iDJwvuCTYqMJR+g3aE2ODyDUdjXskW0uz0nAwQXoHLK+mpqlz0b7u1r 319rNsNhI1n7QUYF8SZyQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:pPzAyLQMfwc=:oZaslvDZjL0tph74aFEpSu Q4aI3DUUb0DL1+h8HYETUa9aUBXwLNCkwvEbQ/RD2gBEKD6yKlKoRbYmjT7LF0M80x3EFIfJG y3vCL2ju/p7+5vLLrofGmEDHECI4QlQTLbL6Nkec/fcfNxzp+e7Q2i+J97zXFhY+SL0jz7mv4 84+KL3LfFNxSFctQCrlGUbWYs6uZSNu4CJ7xj8xBtnrEk1GlkuYoWPI2zJTTydOISCBzqSKKf 6a+8mZVaptO+TXvAL/AQmqgWHcjoP+n5ck8Wt+izvgozgfZZbrwkddl5DHgDK9MxYJgU3qOQh 2Ot/bH8ZsBNfKlO5/1eWHW3Ci7b7m5nhw0DYHwhVyblomCeG7tCsvZoVk+20uJ5NEoJEIJciE TzmzamhDG9QrPP+PenmW4La/NhYUDl7O8Ha3aPp+K1/dyY/4CQkiiem6cdnOWiJILzG7n0nEG b4Q31V40DCr+yGetkgNQQCNh0KUFJWXUaqI1nZSBuvp/UJpO7rf7tkmLO3SNljIh+3mxI0uqZ 4ddiB+Hb4D026LIKaN2eztNHyqmxudFiSj/6XM9VwaJBUf7+ZK31o4yTATKypY3FJ5MIUGfIL OdTP7HrTmOL1cgPqQsXYyo1OgW2KS8xwHX0dT0xbalAMVSQz58p78H42XxD6Qq6cFqa+ZKmHC Ew5rxRjN5hX03jzBrzhL6fDXfErpobQsSlJI9lhQ8JkyllROIebVHzOdD+CcXVlaMXzaKlHQr S8O0qpbOiLJ0zz7g2OqzZzRzp8QUJ9tzlDMMci5yciVB152FIQmCdPGfNCxCvkgxTQM67pvH2 DUKCiZT 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:46:37 -0000 Hi Jesper, > 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: > = 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. This sounds all very reassuring! >=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). 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 Best Regards & Many Thanks Sebastian >=20 > --=20 > 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