From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id E673E3B2A4 for ; Sat, 23 Dec 2017 09:21:14 -0500 (EST) Received: from hms-beagle2.lan ([79.210.211.214]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MGnPx-1eFoNd0XqL-00Dbtn; Sat, 23 Dec 2017 15:21:12 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Sebastian Moeller In-Reply-To: Date: Sat, 23 Dec 2017 15:21:11 +0100 Cc: Andy Furniss , Cake List Content-Transfer-Encoding: quoted-printable Message-Id: References: <31d49a5d-02a2-3dc8-a455-52d453b83bdf@gmail.com> <3b255661-1b16-cc29-958f-bbbedbcbab9e@gmail.com> <8FB76CCB-1AAB-42F6-AEF8-D0D8A438EA91@gmx.de> <7ca86dce-7645-38e8-df4e-148245e9991c@gmail.com> <3B4D3F22-DA08-4A8A-A1E2-C31A2B627727@gmx.de> To: Ryan Mounce X-Mailer: Apple Mail (2.3273) X-Provags-ID: V03:K0:kJXpOqv5h4MeIhzWETTMQtGQnYO/vfMyosbzjVWdF70wLc9uC/J hUiPrrZqjuUuMl5s9MPjDxbn6PS4TqXqHTiyAStG4S2EaC8rWAxCtqYj8E7yjmDkZb/oEME 6VfN2Jkn+ZglmTSK9io9E8hRlql2xsIRRF/P+lp0cHciU83t+vS2Ai1yFtef6k5sSdHNUxk Ha2Lg7FrL0/fBSRVxRs0g== X-UI-Out-Filterresults: notjunk:1;V01:K0:HwM3HWbBd1w=:r+Hc4ptvfifvccl5Fwzukz lKMRR6AFSlpCsGnh6LSQ69YY6cN40FpX/xhS3hzecTIuXltIascJIVkoxNFIMBhDdQt0OJJTm IuEqNZeVzVUW0Z4Pz7dprGZ3gxEONT2BLSZJ+tP+uBtYXsWFs6cDERwl/UPHnta0a2vHYlTFs DKsqYFWrH/uvKl+9cA2OGSuX5bJbJwsMllBeSRSH2Rh0CmNLRS2wX5JqIuRwu6CWws9VnuSgi b0W7/0HQFxOy9UAfKDWl5EUja8wbjDYn6B1calBxHKyDw/hh2xDTdQng6wHWcjZ+yMcYUrTXF n1OvOb2jAJ6W4mgoXS3kYth8JNP0dbLL0b8NbxnxwERS3hGcMeTOz8Z1Z3BdKqjm8uT/flD6J F+/931rsPeJfMY3POIob/s/++c7hP/7TKK4HO9ZbMQ0Q+r7gYsR2AOEriNZffICkJN/VTfsDX 5CNkSmUTBvjlhCxlU0lR8F7In2ygPPbKiuorKrKhdeAJEWGgegwxhIa+wimqbkABwe0KDjvbx uvEYI6X6v3Qyyv21bapbGBZ0ZoH0XY47HG+rIg1+eCtMqQ4Thp5n3+y/vbjkWH57WdW4lnFXu Mw51rmyppGvqcX5iP+z4H29XJZ3JOY7rdLvOR4a2JBMwCXSjICJFop1TSkKI9gKbPhIxyzLQj inB3LEN0SAW/owCieWswUzH2lv5jlRbwxObA24dQFzRIIYneiIOZO+USnsK4jrMN625nYXLjy zKECHu/njvjDMdH/4oJEA5olOEufi0GyPiOn0sVqDof5S58z5YT4IudcP/S14GihjCWitwu8Y edmDmuQZsh8jlipNzJzit3lln9MSKXqx6FXYV6Ti9UeQYQNp6V/oPQL/ccjcOO7XcAy7tle Subject: Re: [Cake] overheads or rate calculation changed? X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Dec 2017 14:21:15 -0000 Hi Ryan, > On Dec 23, 2017, at 14:11, Ryan Mounce wrote: >=20 > On 4.9 I am seeing a max_len equal to my IP MTU of on PPPoE > interfaces, That is the traditional indicator, that the kernel does not = automatically add overhead for ppp interfaces, and that still seems = valid. > for both egress (hard_header_len =3D 26) and ingress via ifb > (hard_header_len =3D 14). Yes, that matches what we saw before... > At least this issue had been offset by the > double-overhead bug for a little while :) I guess we need to retire the automatic adjustments the way they = are done now and I will need to write an instruction how to deduce the = applied overhead manually. That or I try to see whether my idea "compare = the first IP packets skb->length with the value of its total length = header field and report and correct for the difference between the = two... But that requires some research first why the hard_header_len = values for pppoe interfaces are as we see them (my hypothesis is that = the kernel actually accounts for all known overheads for the whole = interface stack (in my case pppoe-wan -> eth1.7 -> eth1) somehow) I guess I should have looked at the actual assumed kernel-added overhead = earlier, but I only went as far as testing real ethernet interfaces. I = maintain that if cake would report the max_len_with_overhead along with = max_len this would have been way more prominent and easier to debug. Best Regards Sebastian >=20 > Regards, > Ryan Mounce >=20 >=20 > On 23 December 2017 at 23:25, Sebastian Moeller = wrote: >>=20 >>> On Dec 23, 2017, at 10:59, Andy Furniss wrote: >>>=20 >>> Sebastian Moeller wrote: >>>=20 >>>>> qdisc cake 1: dev enp6s0 root refcnt 2 bandwidth 19690Kbit = diffserv3 triple-isolate rtt 100.0ms noatm overhead 48 via-ethernet = total_overhead 48 hard_header_len 14 >>>> This looks like expected, the in-kernel overhead is added to = the specified overhead, just like in the past. I really really wished = cake would report the packet size before and _after_ its overhead = addition making sanity checking much easier. BTW tc's stab might be = useful as an external check... I also wonder whether the kernel's = behaviour in regards to ppp interfaces changed between kernel 4.4 and = newer ones, I see the same weirdness: >>>=20 >>> FWIW my pppoe router/pvr/nas box is running 4.1.46. It's a bay-trail = dc board and they are prone to cstate bug locks, which is why I'm not = running anything newer! >>>=20 >>=20 >> Thanks for saving me the experiments... >>=20 >> Mmh, that would indicate that dev->hard_header_len might not be the = relevant variable, it might be necessary to look into the IP packets = total length and the reported packet/frame size to figure out what the = kernel really added (since the kernel addition should not change it = might be enough to do this only for the first IP packet and cache that = value). >>=20 >> Best Regards >> Sebastian >> _______________________________________________ >> Cake mailing list >> Cake@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/cake