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 DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 9F5D03CB3B for ; Thu, 22 Dec 2016 15:02:31 -0500 (EST) Received: from [172.17.3.76] ([134.76.241.253]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MFMIO-1cNPEH0ZAy-00EKiH; Thu, 22 Dec 2016 21:02:29 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Sebastian Moeller In-Reply-To: Date: Thu, 22 Dec 2016 21:02:28 +0100 Cc: cake@lists.bufferbloat.net, Stephen Hemminger Content-Transfer-Encoding: quoted-printable Message-Id: References: To: =?utf-8?Q?Dave_T=C3=A4ht?= X-Mailer: Apple Mail (2.3259) X-Provags-ID: V03:K0:rCiR3cR72L5OVKMayS7VdkSphQaKt6iXuL3fe5zP1T5xcHeWOLe EQK8ERTSD0marH73fBEF5VH4XCO7rpGSuHUST6aCU88BQfqoFmg5BLQf2NoKUkbJINToiXj OhP+Uh7jXFPE91V2nr32w6qmuyYw/wS+c0OpfMB7zgzQJafh67LZURFqKykPA/4Rc3a7/4B OjM4cU02rc4dIAYXlMRtg== X-UI-Out-Filterresults: notjunk:1;V01:K0:rHyDykZKyjk=:An+7tcC0NQv0ihq1TY7PSZ b+FCHVdrM7cS/R/gKYTnQBoeu4HTN95xD8BkU93PJ1nYKsv4OaQoA9I8DUIy6bG4N8EsKtBr5 zCTsTK2jaeV3q6lB3YPDb13rB7+42RR4XEhNGUxRimZoOb2uG4EOlzRoIL6FPr94ZglseiIZu JXQlXEAH4HH9b2NmJIWx4BgP86opXIjawCmY7VsU9sDl3MiJ6cL1mrDbc6ekQPVpPRplYvPxw b/50eQUiO0Fr9RIf3VPovxFi8XjzAfNy/jA9ldXd6ISLdC75wqWXIrT9iKwgh+YQWZyFrdqbu MjygOd5zPRQC9FTjqrtEO2ANocprlboBXfE50Gs1kV/+Oq+84lujr4qSCsIpH11cz3bM8Na30 qUClz0wa5sVxvtfTDxPP0LfqChe9vLnoxO3zDgrmse5yY9wCa+mj3vpMT8PWsjHTyA1Khpz/P wsMcb5fakA8WDCvpDmf4mWX7MQZqAuJoiS+VGQYcX/gBFqftDpdaaEoSwJgmdYfL6hzxvUiCJ Z1Go/+jn6yZ0Cum0VEzdFbinCXXrgQsyZIIOm14cBg/cstqeXdCWu0NsO5Zd6jDJTrmJfYhmU I8qqSr2D9A0YBg8Ttt+w9p+Kj86CWxnAk+8EVe8SqdvO0Svjr/8zRrMWv0lNBDF8W8lU5qCAO QBs13tYvJhyXEYQs+y1RSiunqjkJxELrv46vnVuMc4T09uOErMqB1J5NjSI8HNN8knUXG2oiu mSbHV0eqAYyXEJRD+P6wo7tx8QiDzeQ9kC4GahYzzXe3p0L11TxpVDjgB7e6o6RaVzPv0WOzl XasqYJs Subject: Re: [Cake] upstreaming cake in 2017? 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: Thu, 22 Dec 2016 20:02:32 -0000 Hi Dave, > On Dec 22, 2016, at 20:43, Dave Taht wrote: >=20 > I think most of the reasons why cake could not be upstreamed are now > on their way towards being resolved, and after lede ships, I can't > think of any left to stop an > upstreaming push. >=20 > Some reasons for not upstreaming were: >=20 > * Because the algorithms weren't stable enough > * Because it wasn't feature complete until last month (denatting, > triple-isolate, and a 3 tier sqm) > * Because it had to work on embedded products going back to 3.12 or so > * Because I was busy with make-wifi-fast - which we got upstream as > soon as humanly possible. > * Because it was gated on having the large tester base we have with > lede (4.4 based) > * Because it rather abuses the tc statistics tool to generate tons of = stats > * Because DSCP markings remain in flux at the ietf But does that matter? Is there really a hope that DSCPs will = ever work outside of a well controlled DS/cP-domain? Because inside one, = you can make any DSCP mean anything you want. Trusting ingress DSCPs to = do the right thing and/or be well enough conserved is a lottery ticket. = And also trusting that the right applications use the right = ietf-compatible markings while no app tries to abuse those seems = optimistic. And finally to end-users the problem is not so much which = DSCP to priority bands/tier scheme was used, but rather how to convince = their important applications to actually mark their packets such. > * We ignore the packet priority fields entirely > * We don't know what diffserv models and ratios truly make sense Well, IMHO that is a good indicator that making it configurable = in addition to a few well reasoned configuration seems not the worst = thing to do, no? >=20 > Anyone got more reasons not to upstream? Any more desirable features? >=20 > In looking over the sources today I see a couple issues: >=20 > * usage of // comments and overlong lines > * could just use constants for the diffserv lookup tables (I just = pushed the > revised gen_cake_const.c file for the sqm mode, but didn't rip out = the > relevant code in sch_cake). I note that several of my boxes have 64 > hw queues now > * I would rather like to retire "precedence=E2=80=9D entirely Why? At least it is a scheme that can be reasonably well = described even if it rarely will be a good match for what people want. = What is does get right IIRCC is sticking to half of the DSCP bits... > * cake cannot shape above 40Gbit (32 bit setting). Someday +40Gbit is = possible > * we could split gso segments at quantum rather than always > * could use some profiling on x86, arm, and mips arches > * Need long RTT tests and stuff that abuses cobalt features > * Are we convinced the atm and overhead compensators are correct? The ATM compensation itself is quite nice, the PTM compensation = IMHO is not doing the right thing (less precise and more computationally = intensive than required, even though by probably only little). I still = have not become a friend of the keywords (it does not help that at least = one of them seems not on accordance with the relevant ITU documents). = Then again I am sure the keywords do not need me as a friend. But all of = this is optional and hence no showstopper for merging (as long as none = of them become default options changing them later seems doable to me). =20 > * ipv6 nat? The current believe seems to be that whoever does IPv6 NAT with = a /128 and port remapping can keep the pieces. I have no idea how = widespread such a configuration actually is, and adding an option for = that after upstreaming also seems not unreasonable? > * ipsec recognition and prioritization? Why? Best Regards Sebastian P.S.: The only part where I can claim some level of expertise (for a low = value of expertise) is the overhead accounting stuff, so take the rest = with a smile. > * I liked deprioritizing ping in sqm-scripts >=20 > Hardware mq is bugging me - a single queued version of cake on the > root qdisc has much lower latency than a bql'd mq with cake on each > queue and *almost* the same throughput. >=20 > --=20 > Dave T=C3=A4ht > Let's go make home routers and wifi faster! With better software! > http://blog.cerowrt.org > _______________________________________________ > Cake mailing list > Cake@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cake