[Cake] the Cake stalemate

[Pete Heist]

> On Jun 19, 2018, at 3:41 PM, Kevin Darbyshire-Bryant <kevin at darbyshire-bryant.me.uk> wrote:
> 
>> On 19 Jun 2018, at 13:26, Pete Heist <pete at heistp.net> wrote:
>> 
>> I have a 32-bit MIPS in my ER-X, but it sounds like what I saw (outrageous refcnt values) was something different:
> <snip>
> 
> Yes it was.  At one point iproute’s tc was doing hidden type promotions in printing from 32bit to 64bit types and neglecting to tell the printf formatter of the change, thus printf was starting at the wrong point in memory in big endian environments.  This was part of the move to JSON output.

Ok, that one sounds likely to have been squashed...

> Toke took my bug report & patch and made it acceptable to upstream where it now lives as: https://git.kernel.org/pub/scm/network/iproute2/iproute2.git/commit/?id=4db2ff0db46f6368d89cfb3498a700e1256d2a04 <https://git.kernel.org/pub/scm/network/iproute2/iproute2.git/commit/?id=4db2ff0db46f6368d89cfb3498a700e1256d2a04> and is included in iproute2 v.4.17
> 
>> However, if there’s a way I should try to reproduce something on this hardware to take a look, send any info you’ve got (how to add 64-bit netlink attributes?). I even have a spare ER-X on which I could put OpenWRT in case I need to be working with a more modern kernel…
> 
> The lack of stats on recent (ie post https://github.com/dtaht/sch_cake/commit/af1d7cde7046af55ec867b29854d754816b64bc8 <https://github.com/dtaht/sch_cake/commit/af1d7cde7046af55ec867b29854d754816b64bc8> May 15th) with MIPS BE & LE 32 bit arch is a mystery.  My hack workaround to that for my own personal openwrt builds is https://github.com/ldir-EDB0/openwrt/tree/tokesiproutedebug <https://github.com/ldir-EDB0/openwrt/tree/tokesiproutedebug> - which also includes a debug commit from Toke.

Ah, and I see my OpenWRT build’s kmod-sched-cake is from 2017-01-28, before the dawn of time. Really dumb question- how do you do your MIPS builds, cross-compile? My MIPS hardware is enough to run things but I don’t know if I’ll be installing dev tools and compiling on 64M RAM and 16M flash.

> I got a little further into collecting info on this courtesy ‘kmod-netnl’ which allows packet capture of netlink packets as if on a network interface - captures sent to Toke IIRC but they require hand disassembly to determine where the packet formatting is going wrong.  And there $real_life intervened and I’ve not looked at since/had some more pressing bugs to ponder.
> 
> Openwrt nearly bumped to iproute v4.17 but I haven’t yet got around to seeing if that makes any difference.  It looks like netlink_parse_nested cannot cope with 64bit netlink attributes…. but this requires a person who can code rather than me to go any further.

Ok, this just sounds ugly and I’m not likely to progress on it soon to be honest.

> RE: the stalemate.  I swing between an absolute hatred of anything linux/open source/mail lists and finding some people *incredibly* helpful and thinking ‘it’s not so bad, actually this is fun’.  I offer a very recent example of this where I worked with David Woodhouse on a kernel PPPoATM bug (caused by a ticking timebomb that one E Dumazet left behind ;-) that stretched me to my absolute limits but was executed in a spirit of helpfulness, curiosity & fun.  So it seems to be about finding the right person in kernel land who can both see the errors in our code but also see the value and effort in what we have achieved.  Maybe I’m being unfair and not interpreting the kernel mailing list environment correctly but to me it comes across as abrasive at best (and I swore I'd put my head in a tiger’s mouth and tickle its testicles with a spanner before I even think of trying to submit another patch upstream)
> On the other hand I can also see that had we approached/involved the kernel people earlier on then some of the blind alleys we’ve travelled (I’m thinking passing of netlink stats here) could have been avoided.  Instead we’ve invested years of work and just presented a fait accompli. Whether that would have yielded some of the layer breaking stuff we’ve ended up with I very much doubt and cobalt would have been much, much poorer as a result.

Thanks, I rather agree, I just think that ideally cooperation among all levels of the kernel would yield a total result with more conceptual integrity, and fewer fortified turfs. I wouldn’t stop questioning the stuff that’s been around for years, so whatever we learned in trying to get Cake out there, maybe after it _is_ out there, we should send up some constructive feedback on what could have made it better. Ideally if something useful doesn’t fit upstream, there should either be genuine solutions on how to make it fit, or a re-thinking of the upstream code so it does.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/cake/attachments/20180619/752b5e7f/attachment-0001.html>