[Cake] the Cake stalemate

Tue Jun 19 12:24:13 EDT 2018

a couple notes.

"forking" code and living out of tree for a while has been a way to
spin faster on solving thorny problems, and welcome newer,
less experienced devs to a difficult codebase while encouraging folk
in the problem domain to enter. I am an increasingly
lousy programmer, (for the record my best languages were lisp and perl
15+ years back), and these days far more interested in politics and
theory, than in the grunge of programming (I do confess interest in go
which is cheering me up - I used to learn a new language every couple
of years, but python's "GIL" offended my multi-coreness and rust was
too much like BDSM).

Sometimes I'd like to investigate how "dunbars limit" shapes the linux
communities.

Had we tried to merge cake  earlier making it as feature complete is
it is now would have been harder.

Cake specifically is not modular to gain benefits - it uses one less
packet than htb + fq_codel, which was a compelling enough reason to
pursue it back on day one. I'm oft-boggled by what it has become.

It's also less modular in my (thus far forlorn) hope it could more
easily migrate to codebases outside of linux, not just bsd, but
ns2/3, fuschia, ddpk, and proprietary stuff like whatever is inside a
rdk cable modem, cmts or dslam nowadays. I'm not sure if I've ever
clearly expressed "less modularity" or why as a design goal here...

We did, always, seek some visibility into the mainline linux folk -
stephen hemminger has always been around, eric dumazet aware,
etc. General rule - Always, always have some contact with the core
folk, don't bug 'em until you've got something good - establish
personal contacts, go to a conference once in a while. Drinking beer
with the people you argue with on mailing lists helps. I wish kevin
had dropped in at london ietf. I find it difficult to physically
travel these days, I'm dreading the trip, but I'm seeking contacts in
the ftc,  planning on dropping in at comcast and having ESR and cathy
kick my ass at power grid.

a persistent sadness is we've not had the funds to get to conferences
or even make t-shirts. or do pr. or pay ourselves.

I go through long periods unsubscribed to the netdev mailing list. I
can't stand the patch volume; just watching it go by burns me out. I
feel the pain of those compelled to be on it, and have a great deal of
sympathy for dave miller's irascibility. In person eric, david,
stephen are *great*. Jesper, dave woodhouse, Jon corbet are *amazing*.
so many people are great in person but testy on mailing lists. some
are great on mailing lists but lousy in person....

The main reason why I'm on nedev is to spot interesting new features
and watch bugs get found and fixed, and I'm hoping to get off of it
again a few months after cake makes it in. With a sigh of relief.
Maybe this userspace wifi emulator will get funded. Not feeling burned
out over having to face c or the kernel again feels good.

the cake codebase has benefited hugely by finally getting more review
from the top devs in the field now, and I applaud y'alls persistence.
We'll find this last bug, and then...

everybody can have cake.

On Tue, Jun 19, 2018 at 7:48 AM, Pete Heist <pete at heistp.net> wrote:
>
> 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
> 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
> 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 - 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.
>
>
> _______________________________________________
> Cake mailing list
> Cake at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake
>

-- 

Dave Täht
CEO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-669-226-2619