From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dave@taht.net>
Received: from mail.taht.net (mail.taht.net [176.58.107.8])
 (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by lists.bufferbloat.net (Postfix) with ESMTPS id C22183B29E
 for <cake@lists.bufferbloat.net>; Thu, 16 Nov 2017 14:13:36 -0500 (EST)
Received: from nemesis.taht.net (c-24-6-113-161.hsd1.ca.comcast.net
 [24.6.113.161])
 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
 (No client certificate requested)
 by mail.taht.net (Postfix) with ESMTPSA id 400CE21474;
 Thu, 16 Nov 2017 19:13:35 +0000 (UTC)
From: Dave Taht <dave@taht.net>
To: Pete Heist <peteheist@gmail.com>
Cc: cake@lists.bufferbloat.net
References: <mailman.1019.1510802012.3609.cake@lists.bufferbloat.net>
 <F9CF3DD7-5AED-4EE5-AC47-C31A5AFE1FBE@gmail.com>
 <87shde2nj7.fsf@nemesis.taht.net>
 <1BED94C0-BF21-44BE-A0B0-22224C24C160@gmail.com>
Date: Thu, 16 Nov 2017 11:13:32 -0800
In-Reply-To: <1BED94C0-BF21-44BE-A0B0-22224C24C160@gmail.com> (Pete Heist's
 message of "Thu, 16 Nov 2017 19:40:24 +0100")
Message-ID: <87375e2g0z.fsf@nemesis.taht.net>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [Cake] Cake upstream Planning
X-BeenThere: cake@lists.bufferbloat.net
X-Mailman-Version: 2.1.20
Precedence: list
List-Id: Cake - FQ_codel the next generation <cake.lists.bufferbloat.net>
List-Unsubscribe: <https://lists.bufferbloat.net/options/cake>,
 <mailto:cake-request@lists.bufferbloat.net?subject=unsubscribe>
List-Archive: <https://lists.bufferbloat.net/pipermail/cake>
List-Post: <mailto:cake@lists.bufferbloat.net>
List-Help: <mailto:cake-request@lists.bufferbloat.net?subject=help>
List-Subscribe: <https://lists.bufferbloat.net/listinfo/cake>,
 <mailto:cake-request@lists.bufferbloat.net?subject=subscribe>
X-List-Received-Date: Thu, 16 Nov 2017 19:13:36 -0000

Pete Heist <peteheist@gmail.com> writes:

>     On Nov 16, 2017, at 5:31 PM, Dave Taht <dave@taht.net> wrote:
>
>=20=20=20=20=20
>     Pete Heist <peteheist@gmail.com> writes:
>=20=20=20=20=20
>=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20
>
>             On Nov 15, 2017, at 9:04 PM, Dave Taht <dave@taht.net> wrote:
>=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20
>=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20
>                 Dave Taht <dave@taht.net> writes:
>=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20
>=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20
>
>             https://github.com/ffainelli/bqlmon was a tool for looking at=
 bql
>             more
>             directly.
>=20=20=20=20=20=20=20=20=20=20=20=20=20
>             I had forked it for some reason or another:
>=20=20=20=20=20=20=20=20=20=20=20=20=20
>             https://github.com/dtaht/bqlmon
>=20=20=20=20=20=20=20=20=20=20=20=20=20
>
>         Nice, that does work for me. It=E2=80=99s interesting that there =
are four queues
>         for the
>         igb driver, 00 - 03, and when I try an rrul_be_nflows test, not a=
ll four
>         queues
>         are necessarily used. Once I get >=3D 8 flows in each direction t=
hey
>         usually are
>         though. I suppose this is the driver deciding when to start using
>         another queue
>         or not.
>=20=20=20=20=20=20=20=20=20
>
>     Usually it is selected via a hash. In more than a few cases, however,
>     the designer of the hardware intended it as a strict priority queue. =
In
>     other cases, it's based on the CPU.
>=20=20=20=20=20
>     In all cases such a limited number of queues tends to cause oddities.
>=20=20=20=20=20
>     I think it was the mvneta (?) that had the strict priority queue idea=
 baked
>     into it, which we ended up disabling entirely and going with just one
>     hardware queue.
>=20=20=20=20=20
>
> I noticed when I went to buy the APU2 that the two lower-end models (apu2=
c2 and
> apu2c0) have I211 NICs instead of a I210. The I211 is a =E2=80=9Cvalue pa=
rt=E2=80=9D that among
> other things has 2 tx and rx queues per port instead of 4. I wasn=E2=80=
=99t sure of the
> real effect of this when I purchased them, but for an extra few bucks the=
 I210
> seemed worth it. Table 1-6 on page 13:
>
> https://www.intel.com/content/dam/www/public/us/en/documents/datasheets/i=
210-ethernet-controller-datasheet.pdf
>
>         Cake does seem to visibly reduce the size of the queues.
>=20=20=20=20=20=20=20=20=20
>
>     I generally observe that TSO/GRO/etc tends to make BQL's queues 3-5
>     times larger than they are without those offloads - no way to fix it,
>     short of doing what cake does to peel those apart.
>
> A real nicety of Cake that the world should benefit from.

At a rather large cpu cost.

>
>         For whatever
>         terminal/ncurses weirdness reason though, the bar graphs may be
>         sometimes
>         blowing off the top of my 45 row screen, but it doesn=E2=80=99t e=
ntirely ruin
>         the
>         experience.
>=20=20=20=20=20=20=20=20=20
>
>     Maybe that was why I forked it?
>
> Looks like you forked it to fix a multi-queue problem. I forked your fork=
 to add
> a scaling parameter to fix the bar height. -s 4096 works well for me.

I put in a pull request with all the outstanding patches to the
maintainer. Should have done that 2+ years ago.