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 <[email protected]> wrote: > > On Jun 19, 2018, at 3:41 PM, Kevin Darbyshire-Bryant > <[email protected]> wrote: > > On 19 Jun 2018, at 13:26, Pete Heist <[email protected]> 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 > [email protected] > https://lists.bufferbloat.net/listinfo/cake > -- Dave Täht CEO, TekLibre, LLC http://www.teklibre.com Tel: 1-669-226-2619 _______________________________________________ Cake mailing list [email protected] https://lists.bufferbloat.net/listinfo/cake
