From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (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 56EEB3B29E for ; Tue, 19 Jun 2018 12:24:15 -0400 (EDT) Received: by mail-qk0-x22d.google.com with SMTP id c198-v6so150224qkg.12 for ; Tue, 19 Jun 2018 09:24:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Nxs8UkEY9XN/iDRwwxLUJCfS/fjGgmlQiGqZJLkM/J0=; b=Db4IVk18OYhx5tcbYIuLOTNpGCh6SMX7ELP/NU2AISGVhTa4wPWLGxpcZ0j5T3v7PM IZRyr36f9CBnyDoDorVtyPzXhdg7enrGex+4lW5duTBhbtmohtc4Oj7+ZFoCK6HMdTDr INbLeVdUWByVC+b4eDJWcAw65BP22k3K6ICh+SAqHNBMJfIXPqmlQazJNtJxH/PbEfdE zD03XztUR12058lbGXymvqk0IHgvIK6x66vusENm3SV2/vV84ruK8Uh53D2F3609VZSK wrib9++/afkN1cDLEjybzQ9xH1O0juewLTW5RiI0YgE6ufUeyhDODd4fnijHxEwXYDw9 E5dA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Nxs8UkEY9XN/iDRwwxLUJCfS/fjGgmlQiGqZJLkM/J0=; b=rPbtncMtqJ3LvhUo+B7xldRrg740dF/RiTOTJro4tKTKcyKTOA/lNetGkCivchnfuG CjEcbptrj9uWzoKn4aQtdRTgBdhKeKDB6CCfJ+r6xHWIpNCzWobzs1emE9Z3X4iLMMwg jzEB36Ctp4ogx2TzfT2hmH5I/kO8SGNe4hD5tY2YaJkciLbwviLeJOFtLEhxu029y9hI DVtXC2DY9K7pwsfaNoBGUESsW4a9luhFOA41l7AIyvcSfQTRgEVFR8OxW/qwWZVp0sxm SDiZqwvJuvj6Tna7GizXMmeNDZeRkU4l9QxkF+z4Apv3mnq3TV4KXnd1row42upHSRwr yvaQ== X-Gm-Message-State: APt69E0cHWwPAyypxwoYXOIdW3niT9Q8uHpar5TLDy3+j++seaGRVSMz kDWOBAGY0wg3F7+79ObVA4QkejuZXnq7QBeF7Ws= X-Google-Smtp-Source: ADUXVKLuJUN/+vXk5gXJJEpvh1rGaGuQcymxxTVuZjyvZbvk2Ijq4UJ33hadD4chRc1go9fyyLbfB/YC/ATURrqQ24E= X-Received: by 2002:a37:646:: with SMTP id 67-v6mr13992609qkg.35.1529425454832; Tue, 19 Jun 2018 09:24:14 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:aed:24f0:0:0:0:0:0 with HTTP; Tue, 19 Jun 2018 09:24:13 -0700 (PDT) In-Reply-To: References: <87in6ft81g.fsf@toke.dk> <0FF888EC-4FF0-4AAE-B2B8-79A10B0B5A9E@gmail.com> <877emvt2ij.fsf@toke.dk> <6D5348AC-921E-49D3-B6D0-9CC30874B80D@heistp.net> <1CC8F6F6-94E1-4987-928E-29BDE01787BC@darbyshire-bryant.me.uk> From: Dave Taht Date: Tue, 19 Jun 2018 09:24:13 -0700 Message-ID: To: Pete Heist Cc: Kevin Darbyshire-Bryant , Cake List Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [Cake] the Cake stalemate 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: Tue, 19 Jun 2018 16:24:15 -0000 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 wrote: > > On Jun 19, 2018, at 3:41 PM, Kevin Darbyshire-Bryant > wrote: > > On 19 Jun 2018, at 13:26, Pete Heist wrote: > > I have a 32-bit MIPS in my ER-X, but it sounds like what I saw (outrageou= s > refcnt values) was something different: > > > > Yes it was. At one point iproute=E2=80=99s tc was doing hidden type prom= otions 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= =3D4db2ff0db46f6368d89cfb3498a700e1256d2a04 > and is included in iproute2 v.4.17 > > However, if there=E2=80=99s a way I should try to reproduce something on = this > hardware to take a look, send any info you=E2=80=99ve got (how to add 64-= bit netlink > attributes?). I even have a spare ER-X on which I could put OpenWRT in ca= se > I need to be working with a more modern kernel=E2=80=A6 > > > The lack of stats on recent (ie post > https://github.com/dtaht/sch_cake/commit/af1d7cde7046af55ec867b29854d7548= 16b64bc8 > 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=E2=80=99s 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=E2=80= =99t know if > I=E2=80=99ll be installing dev tools and compiling on 64M RAM and 16M fla= sh. > > I got a little further into collecting info on this courtesy =E2=80=98kmo= d-netnl=E2=80=99 > which allows packet capture of netlink packets as if on a network interfa= ce > - captures sent to Toke IIRC but they require hand disassembly to determi= ne > where the packet formatting is going wrong. And there $real_life interve= ned > and I=E2=80=99ve not looked at since/had some more pressing bugs to ponde= r. > > Openwrt nearly bumped to iproute v4.17 but I haven=E2=80=99t yet got arou= nd to > seeing if that makes any difference. It looks like netlink_parse_nested > cannot cope with 64bit netlink attributes=E2=80=A6. but this requires a p= erson who > can code rather than me to go any further. > > > Ok, this just sounds ugly and I=E2=80=99m not likely to progress on it so= on 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 =E2=80=98it=E2=80=99s not so bad, actually this is fun=E2=80= =99. I offer a very recent > example of this where I worked with David Woodhouse on a kernel PPPoATM b= ug > (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 se= e > the value and effort in what we have achieved. Maybe I=E2=80=99m being u= nfair 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= =E2=80=99s > mouth and tickle its testicles with a spanner before I even think of tryi= ng > to submit another patch upstream) > > On the other hand I can also see that had we approached/involved the kern= el > people earlier on then some of the blind alleys we=E2=80=99ve travelled (= I=E2=80=99m > thinking passing of netlink stats here) could have been avoided. Instead > we=E2=80=99ve invested years of work and just presented a fait accompli. = Whether > that would have yielded some of the layer breaking stuff we=E2=80=99ve en= ded up with > I very much doubt and cobalt would have been much, much poorer as a resul= t. > > > 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=E2=80=99t stop questioning= the stuff > that=E2=80=99s 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=E2=80=99t fit upstream, there should either be gen= uine > solutions on how to make it fit, or a re-thinking of the upstream code so= it > does. > > > _______________________________________________ > Cake mailing list > Cake@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cake > --=20 Dave T=C3=A4ht CEO, TekLibre, LLC http://www.teklibre.com Tel: 1-669-226-2619