From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-x229.google.com (mail-wr0-x229.google.com [IPv6:2a00:1450:400c:c0c::229]) (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 2E19C3B29E for ; Tue, 19 Jun 2018 10:48:27 -0400 (EDT) Received: by mail-wr0-x229.google.com with SMTP id d8-v6so20890176wro.4 for ; Tue, 19 Jun 2018 07:48:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heistp.net; s=google; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=gswYb5wthDMgOR7gVNJU74bX1CoscDtdDwj8g+hn8wQ=; b=EXmpSGXlKTVsUkpJM0hgW4mOde38BOM8kc8oubZOgLXNfwN1oSbqN7qbXQWPfIQ5f6 4Xv3W8hQcxamM0nKY3wrF3z2cHbijVdEGY1d4L7p4BvJfQ+1qWWb4Yy7ocWhzHslGao4 1GI7DxIwRPKa97Pqrmf8/p2M161wiw0KQh3Ezm/I2GFp0cH5uXss2INKnb5ONaOOBK+D e+qWNc/uxHqsXxJ43BadR0idaRJ0lJOWLfNmUkF0wixT5wpVx6iAnwmQjHbPFIAJb01y SFxuP7766tASsPBWqqziq20tJj3hODSzQH5r+Y4Iw+V8gY1fgtvcgNpqaV098Bb9NIMN Dy8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=gswYb5wthDMgOR7gVNJU74bX1CoscDtdDwj8g+hn8wQ=; b=YVfnlRRUWoXlEphbZkOCRgsCVXp2AbbBm94qc5KU31lGxdOgjROBrue4BzA/ToVLac G6ITZDJ2LMmqBos8FEIHznVoOI4SpSlE/8RE4CBwT4IpD/ruRqtRrTm215Z8rVzkAwHl uCsPtLK/VxmCGLYWaHXsDqsWw8FH5/+S+DcrBb6rzx5+KSqckhMmxG57kMW2wm93i+qB cnhaIPgYFe/CmVVFQoHDvF9ZNzpMvkJHz3O7q09O0wJ0K6kbZseYxT4Iu6xMReyMGrzE mBd8BaRYKWAUawnsvbMXazk5hOhYEyLFEYWdtoHyE5QZiBhBPmcPxKwX0HwPGut1R2v8 jPzQ== X-Gm-Message-State: APt69E3ZNBTBrgxNUn/RKgpW0eroda2aVZ69J1HiR2zqQPgUhto1M09q 6vLdiRLm/ugxIg/kegC5Ul9dCT+6k3g= X-Google-Smtp-Source: ADUXVKKcQVGjuK6T8ylbU9sEVxM3J18fx4NikSxnJQIHtK/69iPM02qKa5725PAwpbgxOE7+Gne3Mw== X-Received: by 2002:adf:f18b:: with SMTP id h11-v6mr15369879wro.214.1529419706222; Tue, 19 Jun 2018 07:48:26 -0700 (PDT) Received: from tron.luk.heistp.net (h-1169.lbcfree.net. [185.193.85.130]) by smtp.gmail.com with ESMTPSA id f81-v6sm398662wmh.32.2018.06.19.07.48.25 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 19 Jun 2018 07:48:25 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_D57075E2-A749-4189-90D8-246F0A7C12EB" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Pete Heist In-Reply-To: <1CC8F6F6-94E1-4987-928E-29BDE01787BC@darbyshire-bryant.me.uk> Date: Tue, 19 Jun 2018 16:48:23 +0200 Cc: Cake List Message-Id: 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> To: Kevin Darbyshire-Bryant X-Mailer: Apple Mail (2.3124) 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 14:48:27 -0000 --Apple-Mail=_D57075E2-A749-4189-90D8-246F0A7C12EB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jun 19, 2018, at 3:41 PM, Kevin Darbyshire-Bryant = wrote: >=20 >> On 19 Jun 2018, at 13:26, Pete Heist wrote: >>=20 >> I have a 32-bit MIPS in my ER-X, but it sounds like what I saw = (outrageous refcnt values) was something different: > >=20 > Yes it was. At one point iproute=E2=80=99s 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=3D= 4db2ff0db46f6368d89cfb3498a700e1256d2a04 = and is included in iproute2 = v.4.17 >=20 >> 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 case I need to be working with a more modern = kernel=E2=80=A6 >=20 > The lack of stats on recent (ie post = https://github.com/dtaht/sch_cake/commit/af1d7cde7046af55ec867b29854d75481= 6b64bc8 = 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 flash. > I got a little further into collecting info on this courtesy = =E2=80=98kmod-netnl=E2=80=99 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=E2=80=99ve not = looked at since/had some more pressing bugs to ponder. >=20 > Openwrt nearly bumped to iproute v4.17 but I haven=E2=80=99t yet got = around 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 person 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 = 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 =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 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=E2=80=99m 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=E2=80=99s 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=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 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=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 genuine solutions on how to make it = fit, or a re-thinking of the upstream code so it does. --Apple-Mail=_D57075E2-A749-4189-90D8-246F0A7C12EB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Jun 19, 2018, at 3:41 PM, Kevin Darbyshire-Bryant <kevin@darbyshire-bryant.me.uk> wrote:

On 19 Jun = 2018, at 13:26, Pete Heist <pete@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=E2=80=99s = 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/co= mmit/?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 = case 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/af1d7cde7046af55ec867b= 29854d754816b64bc8 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 flash.

I got a little further = into collecting info on this courtesy =E2=80=98kmod-netnl=E2=80=99 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=E2=80=99ve not looked at since/had some more = pressing bugs to ponder.

Openwrt nearly bumped to iproute v4.17 but I = haven=E2=80=99t yet got around 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 person 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 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 =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 = 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=E2=80=99m 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=E2=80=99s 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=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 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=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 = genuine solutions on how to make it fit, or a re-thinking of the = upstream code so it does.

= --Apple-Mail=_D57075E2-A749-4189-90D8-246F0A7C12EB--