From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (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 DBB5D3B2A4 for ; Sat, 23 Dec 2017 16:03:24 -0500 (EST) Received: from hms-beagle2.lan ([79.210.211.214]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0M4TgW-1fBlUk45am-00yjHe; Sat, 23 Dec 2017 22:03:23 +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 22:03:21 +0100 Cc: Cake List Content-Transfer-Encoding: quoted-printable Message-Id: <7416D2DC-A95B-40EA-B7AB-000BF9D113F8@gmx.de> 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:dCdfPrUxn2TsEIN0a2yj0HUETqqUmJMpm1uAlfOokrAaaiqFgG2 1GLI3KGgTJgmXZfiwob2VwTHqJrTWRAjTrOoyqDsPNRAJ1FLWhjtxMjmXN86ehhJhLzD8MT BjT15rT1PVp9Zge6Q75+cR7PYHcnWtNpmXac3xj/m+E+gShmsheiSjvcBjF/3Yklrjsw4bZ zVzwK0t4joq/4McUWhwig== X-UI-Out-Filterresults: notjunk:1;V01:K0:kUW0zvqfEss=:Yn//evTvCsyZINu/tw6L2H fhAvUThZnIrE83mSmmPPvO7OwKRM5MN8wE2LjYx162z62CmThzFdiIS12MyrvimYGHAv42KE3 4AAqPHQILtsGQcuw4TCRXXMuQbdMdRGi9u8CS8c5DCetCmWhwBzo0qNJZ+mMEuEipi3SNzsOf 8+GWUjeJHxLA/e/yjXD/N0GUBfHEMpiQWkkQgHmDZ4BOqS2myBkoZyPCPrdVBdDW9uSt7yK9Z XhIeP1o2JGPfH7v+tFZbrSdiQ70XXtNvj2cuCzYcSpGcqr6sdqfuVHhzYiwRbFP5nbFYLCLfZ lsIjhKQbKbZbrpQrnFzODmwTdsRRX6jJzQp95Su4/3tbTbyH6qZeFM+RYJ2BLhPs/hPCaqbNh v7H42Tz/8FgNlWPwu05HB0+uOmGydbAVvxG8TzfQ/iS8yGrUIDLpcPtOw6p/PDWqE7YaFt8aI QGGNFUv+q5V/XwnjQWl8+9IevURZgRJb5vdUNtzo3i14cnd7OLNhcPBHQRySaFTlcbx+RajHp I7ZDZ1bKAQG0gzxK1frRE3jq0h6R0j0Q16L3FzPXDR6ag+0m00m2+ON+1XZ5Ub2sMXEVsBoQv IgTViLP8zfGdloTsSzlemxHOGlAv4lZBv6pkT0uIb7jLFs+vZqBI09aPzYaLvLx0E3pt5CEJa c+V4rFmOlpuDF+Q5LdAB3GiXeUmOjww9zrD+0z/IhtXcwWPEKy+hdaAWU30et+pQJ4CTHVrvB tb+DH3kuvfyCAny7LiU+jftd1xBzMhqCU8iMCEbRLOJz0zCqjCnGuzqe/2olZGIPyJvQ79qbG GScsi9CpLXsvsvZLGiKQ7q9b505fFqwh6tZLxg+M/FrHK+th4MikP3dlH7muJsaxo0SxgFI 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 21:03:25 -0000 Hi All, just had a look for hard_header_len in the linux kernel: linux/include/linux/netdevice.h: * @hard_header_len: Maximum hardware header length. * @min_header_len: Minimum hardware header length this seems to corroborate our observation that hard_header_len is not a = veridical representation of the actual hardware header length, so I = assume the values cake returns are actually true. It also indicates that = except for pure ethernet interfaces hard_header_len is _not_ the right = parameter to evaluate for what cake is evaluating it for... Best Regards Sebastian > On Dec 23, 2017, at 15:21, Sebastian Moeller wrote: >=20 > Hi Ryan, >=20 >=20 >> 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, >=20 > That is the traditional indicator, that the kernel does not = automatically add overhead for ppp interfaces, and that still seems = valid. >=20 >> for both egress (hard_header_len =3D 26) and ingress via ifb >> (hard_header_len =3D 14). >=20 > Yes, that matches what we saw before... >=20 >> At least this issue had been offset by the >> double-overhead bug for a little while :) >=20 > 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. >=20 >=20 > Best Regards > Sebastian >=20 >>=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 >=20 > _______________________________________________ > Cake mailing list > Cake@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cake