From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl0-x236.google.com (mail-pl0-x236.google.com [IPv6:2607:f8b0:400e:c01::236]) (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 347B73BA8E for ; Sat, 23 Dec 2017 08:11:43 -0500 (EST) Received: by mail-pl0-x236.google.com with SMTP id b96so14405046pli.2 for ; Sat, 23 Dec 2017 05:11:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mounce.com.au; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=8P5U9Wjbrx89gD8/u8t5h0cCwQ2N0kUUoMX7kPG/vY0=; b=F5aCxpCPniE49dje4UNYyRS1c7RLmN6IvW207xYfmpxRl2uhC0TV8ngBZG9/jspVLG WHpPgpobQ21ZBrjPN4EUjMWEyj1MPUst2N3puBfbKO/H04rPF0Jma67KRW/2QUBSvTp3 q+Ml7B67VQSYQCfdHU8p04ZdEzGGAAs1plGdNSm+FJGku3jScThoW2LldhdY9deeTsX8 G88HlVSWe6c6bOM9h74noD+luHnqUD56sYtfbRdoaJyMVcO+0vBdr7GhuZozV51Y98CP xc8Tovmw1jdiVK0HIl/6+BVhjev29IkLg42TDw3WmC8Rv3kPMI6275fX4yHWDAR0K416 LyAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=8P5U9Wjbrx89gD8/u8t5h0cCwQ2N0kUUoMX7kPG/vY0=; b=NDn06qgXcdzyXUJK2vBoejsFNsyHwdnVcqihNT6oK9fyB0EglYLmXEfIEu1gWBmRnO JIpv/Ef4xihs0cNJNnxmQ53Vj8x372ILUT3CMNsJSUFz1mnaQXOMC0GQ4gfKZuVVZNCn kD9y8Br8F7GV6zMmhXjMsLkAWLJLbjcs+F+LjotNiVuNaKv8cwnrmzuetKeAKHhbUAPh Tz7JuBUjQsYN2skD/H3HU6CaLwwvUe5KOgdDDBCzvrFfin+b4jiBou8Jcp3Wix4rhSfl V4c52GQHS4nMPcajWhLJkDviKXe2ZxH7ODVDE8drV2ASoO9LDueHA87DIZ3NsbGxo8Eb +n5w== X-Gm-Message-State: AKGB3mKP53playnLf6lnqYI/BFGC8Y7ljweOZ0DPVzpT2TYstrDHZre4 9od8H9pyQyMrXtEx43oztRoHpZPtWtWPEIH98YzvOA== X-Google-Smtp-Source: ACJfBovJExzCYqBClaAN/Wu7aut6rpi0Ko7ZRKlBQwi0anpk3+1brvgw054vlukPtfJBTUFjUHX9Eq0sd0uhheh3JUU= X-Received: by 10.84.137.1 with SMTP id 1mr17042225plm.333.1514034702208; Sat, 23 Dec 2017 05:11:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.187.3 with HTTP; Sat, 23 Dec 2017 05:11:26 -0800 (PST) X-Originating-IP: [1.123.8.232] In-Reply-To: <3B4D3F22-DA08-4A8A-A1E2-C31A2B627727@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> From: Ryan Mounce Date: Sat, 23 Dec 2017 23:41:26 +1030 Message-ID: To: Sebastian Moeller Cc: Andy Furniss , Cake List Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 13:11:43 -0000 On 4.9 I am seeing a max_len equal to my IP MTU of on PPPoE interfaces, for both egress (hard_header_len =3D 26) and ingress via ifb (hard_header_len =3D 14). At least this issue had been offset by the double-overhead bug for a little while :) Regards, Ryan Mounce On 23 December 2017 at 23:25, Sebastian Moeller wrote: > >> On Dec 23, 2017, at 10:59, Andy Furniss wrote: >> >> Sebastian Moeller wrote: >> >>>> qdisc cake 1: dev enp6s0 root refcnt 2 bandwidth 19690Kbit diffserv3 t= riple-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 s= pecified overhead, just like in the past. I really really wished cake would= report the packet size before and _after_ its overhead addition making san= ity checking much easier. BTW tc's stab might be useful as an external chec= k... I also wonder whether the kernel's behaviour in regards to ppp interfa= ces changed between kernel 4.4 and newer ones, I see the same weirdness: >> >> 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! >> > > Thanks for saving me the experiments... > > Mmh, that would indicate that dev->hard_header_len might not be the relev= ant variable, it might be necessary to look into the IP packets total lengt= h and the reported packet/frame size to figure out what the kernel really a= dded (since the kernel addition should not change it might be enough to do = this only for the first IP packet and cache that value). > > Best Regards > Sebastian > _______________________________________________ > Cake mailing list > Cake@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cake