From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 63B063BA8E for ; Sun, 7 Jan 2018 03:19:41 -0500 (EST) Received: from hms-beagle2.lan ([79.210.208.213]) by mail.gmx.com (mrgmx003 [212.227.17.190]) with ESMTPSA (Nemesis) id 0LqzIJ-1f31LN0Tfn-00ehE1; Sun, 07 Jan 2018 09:19:38 +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: <202188C4-062D-430B-838B-EAFEDB394002@gmail.com> Date: Sun, 7 Jan 2018 09:19:35 +0100 Cc: Ryan Mounce , 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> <7416D2DC-A95B-40EA-B7AB-000BF9D113F8@gmx.de> <202188C4-062D-430B-838B-EAFEDB394002@gmail.com> To: Jonathan Morton X-Mailer: Apple Mail (2.3273) X-Provags-ID: V03:K0:LvL9Dy2dQHNUoN5P8Gh/q7sQGQZRC6LEggDFsgb6gZi9FiTOJ/H uIXNsnKqZ3uXggAN67kta0rknWS/mUssgLfCxLwYlLdUHGVck6JU7RPFfYoz6NxIuASlknr 0LqLM2gbrbk2nwsyRxchescY56UdnXXzBF+l6qRFl1Hff0l5xGcuzdSZjp7qMUwA6h8ma10 g6fx5AfXQWFK2tjBtBnyg== X-UI-Out-Filterresults: notjunk:1;V01:K0:d+0pQLjZcTw=:HJ2o2EkVwHBbQveFshAIh3 XYeonb6hv0+/UOHJ/vcwFpUtD7Vx3jDJI30fSLBJL0zQ4mIkgk4FcosOtTlN26rfjIXNdKJOw E1PmsjQY3R747WZY3nSMn7lMlgfKHFfA6hurI1u8BpnMKvmtVuA2GJ6YkE7W54YWzzEC8KFOR 6hsMZMXtNnUEJgcFjTK45xWhcl5inAmL+xHLDJJ80pFaSmBDt5wwktrj1eaLbBX3x8GriV3sS VyVLVauhyHFNOthls270QXd+SZJ7A6mNaBxwgqeka4Ui+PtaJTAplinF8QAtjzekRsk/Sp7C7 CYGIMiS+58ICc2gpiYPZV31OK/dhfy1J3quCsQo5lKgvaYmaEzCjelM9jR6ya7uqFMh5/kkx0 OnfJrpM4bPJSRmuOZEAHLpOHFk2pXUtsCYhz6nZCrGG+OHwcLMRjLVlxe+kMOtOGZQpEynqsU chmMEaXYV71wHbiyLKL+PdyUgcXz1MoP9BSY0N3XBhJYonPjyjpVilvOgDL31HrFcaXwcKavg u1mMvadOPm90jhh24DrtBym/aqN3AtsH2NOXYKjxfgjI/v6etDx7G0RMXmFZlT3hSKl9f44Qb xkPG1ChDvvXDOBN2qOZZ3kcjB3eM2W8zZ+2srsylfe48C6P/OlZnK6jjzbyLJw6L7WhZVAFmd +IU6TaIIO74p8a8xyKxHGJP5iRqu4Hiet/RwxNYSu/gnu0atIx3WXb7wdAHnjT18DOq5cHRpr QyiSW5SwK7wr3YwaAG9ni+5LE29E7ewW7B5ECheqZbmjvbNNP6YqT2ehEJN90GEjdS1Hj99OR G2H9JX13G0mYRAkH8tNNWm4K6gWc6yISqo3gJjnqPu4BOotrUM= 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: Sun, 07 Jan 2018 08:19:41 -0000 Hi Jonathan, > On Jan 7, 2018, at 01:33, Jonathan Morton = wrote: >=20 >> On 7 Jan, 2018, at 12:46 am, Sebastian Moeller = wrote: >>=20 >> I thibk cake should offer a mode in which it behaves as all other = qdiscs currently do and not do auto correction at all and a mode where = it corrects for the right amount, but keeping the current ake cbehavior = will not help anybody.... but most likely i misunderstood your proposal = in that regard. >=20 > Let me explain a little more clearly, using your example: >=20 > Here "by default" means with no overhead keywords used at all. = Currently, Cake does nothing with the packet lengths by default, acting = as though "raw" was specified. Yes, I believe we should keep a mode that does exactly that, but = this might be done with an explicit keyword IMHO. Not having that would = require that cake always does the right thing and as the history of this = feature shows, this is hard to guarantee. >=20 > Instead, Cake will act as though "overhead 26" were specified on = egress and "overhead 14" on ingress in your case. =20 > Unlike its current behaviour, it will recognise that it's actually = getting raw IP packets, and won't first attempt to subtract a = non-existent header from them. That's still different from tc-stab = behaviour, but probably more useful. Why behave like "overhead 26" was specified? The really desired = behaviour seems to subtract (skb->len - IP packet size) and neither the = 26 nor the 14 where actually added to skb->len. So I a still confused = about what you propose cake to report. BTW do you see a 100% correct way to get to (skb->len - IP packet size)? >=20 > Conversely, with a typical Ethernet interface, it will act as though = "overhead 14" were specified on both egress and ingress, and will = effectively leave the packet length alone, recognising that there is in = fact an Ethernet frame header on the front of the packets handed in. Ah, I begin to understand my disconnect; this is not ideal = behavior as with the overhead accounting we want to be able to "model" = the bottleneck overhead and not only the shaped interface overhead; = think shaping for an IPoA link (IP over ATM) from a non-ATM router = connected via ethernet to the ATM-modem, the 14 bytes kernel accounted = overhead are neither required nor desired, if I specify overhead 10, the = kernel ideally will pass (for a full MTU 1500 packet): 1500 (MTU) + 14 (kernel added MACs/ethertype) + 10 (specified cake = overhead) - 14 (remove the kernel-added MACs/ethertype) Now, if you only talk about the case that the user did not specify an = overhead in the cake invocation, using the 1514 skb->len without further = modifications, than we violently agree. We really need this "behave like = all other qdiscs" mode so that cake can be used with "tc stab" exactly = as awkward as all other qdiscs, it would be really unfortunate if cake = would require different "tc stab" magic than say HTB+fq_codel. >=20 > If you then specify "overhead 34", you'll get exactly that, relative = to the transport-layer packet (that is, IP). That is the best thing to do agreed, but from your description = above I am not sure about the exact conditions you propose to do that. >=20 > You'll get visibility into this behaviour through the output of the = current configuration, which will include an overhead keyword. And all = this assumes that skb_network_offset(skb) *actually* does what I think = it does. The overhead keyword is nice in that it shows what the user = requested, but we really NEED to report also how cake interpreted that = request, so we NEED to explicitly report the auto correction value in = addition to the requested overhead (and for ease of use we maybe should = also report the amount of overhead cake added to skb->len (which equals = (requested overhead - auto correction value))) >=20 > What I'm not sure about yet is whether to keep "raw" I am not that impressed by the overloading that raw already has = (ATM, PTM, overhead...), but the functionality to not-do the auto = accounting seems required (unless we guarantee that cake always does the = correct thing; and for that we need to explicit;y report what cake "did" = and what the user asked it to do). > and "via-ethernet" with their current meanings - THe current via_ethernet behavior seems not requred anymore, = ONCE we unconditionally report the amount of auto corrected overhead = (which could well be 0). > as that would probably have a (small) runtime overhead as well as = requiring more serious thought into how to organise the configuration = interface. =20 > Otherwise, I do intend to keep "raw" as a way to reset to the default = configuration. That is not what raw does ATM, for the via-ethernet mechanism = raw is not the default (how a bout a new default compound keyword?) Best Regards Sebastian >=20 > - Jonathan Morton >=20