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 C33EC3B29E for ; Tue, 5 Sep 2017 11:06:58 -0400 (EDT) Received: from [192.168.250.101] ([134.76.241.253]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0M5q45-1da1o43ccb-00xpv7; Tue, 05 Sep 2017 17:06:53 +0200 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: Tue, 5 Sep 2017 17:06:52 +0200 Cc: Kevin Darbyshire-Bryant , cake@lists.bufferbloat.net Content-Transfer-Encoding: quoted-printable Message-Id: <704C0FDD-7312-47E3-949A-21F06BA0C36A@gmx.de> References: <51c4c54f-dc20-739c-3ee8-eb629cddae24@darbyshire-bryant.me.uk> <538A474A-8A75-4909-A386-2095817D4D0D@gmx.de> To: Ryan Mounce X-Mailer: Apple Mail (2.3273) X-Provags-ID: V03:K0:u+v5wAzBaK2Gm21ELAGCXpjzd2+vItWAzjGrFS9SKxGTw7tv6hU uWqNxyuMnlpmIjqYIRv4ZKetgCInT5GxKBrhRmNXWRR8saucSREmrPSUOv8zgT2cweYMWzI M6zhBhpaSD6YGi2zsg+ytwj8j7MxJrCiihy1L5NnfNWqXxA/yOsqlcogOTRpaDyd1FYLsH0 dRFjwJ6Ms+GWohMLS4vaA== X-UI-Out-Filterresults: notjunk:1;V01:K0:4wAtVaOIXGA=:nUqwQGhChuf1S9pYK5cOr9 vv8JM0AjNohX7gtGCs5U7X8A7P2K9AmIgOYNsCy+Zu44Bu5C5Pep+VoX5zeuaXd+nY/2OO5gl K9vD+InDVlnTl2+8uM89TO7/3WbGpKTrGZU96K88UBSswFqNMBnrCxd9LiJpTU9fPXfRRyjyi TQ1XQ8jMj3nYPKfAij1E522rJCe2DJPdUNxXGMn2mKx5QngIaY/V0YAQ5H/UNaG1URpKvNswV 9LVIGFBPoHVPR46bAKzpx3TOVnmPs/+mtIz76x5dZDXpCzbkRGPfwD9yDh/aWD7bDaKPZWGtj JJKklceXaRUk6EIsnNmnj2mn+JhzeREy/6cCSZ4XJ9fgzxby1jXhRET7/QLBX7m5Zr2sximQe q27YTIxtdujTGgkTiIAXqGZnPod/9d5relA6Vx6NvVPUfGVIvsD/zQ2hHrgmrwtbuG5PWcl9Y DRL0t2W+GkneSXNxkWceLrWIFS5C0c1tSvX3dvDmApfgtdQiOf5ifek3qnzz1xua1uPfzBzJI SPQ21shFOVqcGxp0BuoPgEEvBvskvHht03HAnj/ms+COolicszmcJk/8si/c6aGWod9m/X6DN EGRtvVKMSfr85a5aS2F+bqraK3ur6/8VOIdJKDBvrFl1VvHF8ZFeE0L6kVJ4tNgzsuXTwL4PR 68IH+DLhn9j2toNCa7eV9T8Y2DaFfpZOgB3pqJw7xxKFCAzfox8iiSu3NbmkWYfRfOevdYN0P 9CFZn4OhbW41MbtxZyK4KrNTvpB7oh9exnSQ4cLH9jWhRdf02HoIk+fby3iYM94ftvGHYc6n/ TJ0oSs7jqFP2fChDtE+t90Hlo+lCy2Z+/qpouetSM1xkBwx1Uw= Subject: Re: [Cake] overhead and mpu 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: Tue, 05 Sep 2017 15:06:59 -0000 Hi Ryan, > On Sep 5, 2017, at 16:37, Ryan Mounce wrote: >=20 > On 5 September 2017 at 18:28, Sebastian Moeller = wrote: >> Hi Kevin, >>=20 >>=20 >>> On Sep 5, 2017, at 10:35, Kevin Darbyshire-Bryant = wrote: >>>=20 >>>=20 >>>=20 >>> On 05/09/17 09:01, Sebastian Moeller wrote: >>> >>>> I believe this is used internally so cake can deduce the size = of the automatically added overhead (the linux kernel will add 14 bytes = on ethernet interfaces automatically, which while certainly justifiable = are not the ideal value for an ethernet shaper); with this cake allows = the user to specify absolute overhead (so if you specify overhead 18, = cake will give you 14 - 14 + 18 =3D 18, while tc's stab method will give = you 14 + 18 =3D 32). So cake is doing the right thing here (the only = thing it could do even better is to report the size of the automatically = corrected in-kernel hard_header_len, but then the audience for that = information is probably to small to justify this feature). >>>=20 >>>=20 >>> Actually for the sake of a one line change in the tc code it is an = extremely useful confidence boost and info source as to just what linux = thinks the overhead actually is: >>>=20 >>> // This is actually the *amount* of automatic = compensation, but we only report >>> // its presence as a boolean for now. >>> if (ethernet) >>> - fprintf(f, "via-ethernet "); >>> + fprintf(f, "via-ethernet(%d) ", ethernet); >>>=20 >>> I've run that in a local patch to tc on LEDE for AGES. Very useful. >>=20 >> That sounds like it would be a great addition, since the = information is already collected... For what it is worth I would vote = for adding this... (to the version that should be upstreamed ;) ) >=20 > +1 >=20 > It would also be nice for tc to know whether the overhead has been > explicitly configured and report appropriately. In my case I use cake > on a VLAN sub-interface that happens to have a hard_header_len of 18 > after the 802.1q tag, and then use the docsis keyword to more > explicitly configure the overhead in case I move to an untagged > interface in the future. tc -s qdisc can't tell the difference and > reports 'raw mpu 64' rather than 'overhead 18 mpu 64'. Ah, I see, when ever the explicitly requested overhead equals = hard_header_len, cake does not include it in its output. I believe this = would be nice to change to always explicitly report the overhead (so = even default to hard_header_len if no overhead was specified otherwise).=20= Since the keywords like docsis are really convenience wrappers (hace a = look in tc's q_cake.c) I vote for always expanding to the explicit = overhead and potentially MPU values instead of reporting the keyword = used. I believe manually specifying "overhead 18 mpu 64" will be just as = future proof as the docsis keyword in regards to changing = hard_header_len. It has to, in the end the docsis keyword gets interpreted by tc as: /* * DOCSIS cable shapers account for Ethernet frame with = FCS, * but not interframe gap nor preamble. */ } else if (strcmp(*argv, "docsis") =3D=3D 0) { atm =3D 0; overhead +=3D 18; overhead_set =3D true; mpu =3D 64; =20 Best Regards Sebastian >=20 >>=20 >> Best Regards >> Sebastian >>=20 >>=20 >>>=20 >>> Kevin >>> _______________________________________________ >>> 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