[Cake] CAKE related iproute2 & kernel patches - keeping things in sync

[Cake] CAKE related iproute2 & kernel patches - keeping things in sync

[Kevin Darbyshire-Bryant]

[-- Attachment #1: Type: text/plain, Size: 1096 bytes --]

To whom it may concern (Dave) ;-)

This is a general plea that when patches are submitted to upstream please can we also commit them to our current development repositories.

4.19 isn’t even released yet, so most people, including Openwrt, get cake via our 'out of tree’ repositories.  This is also a good idea from a point of view of testing.  I appreciate the latest changes are of ‘one line’ type variety and so mostly harmless but ideally it should at least be in our own out of tree repo’s first/at the same time.

I had to submit the latest ‘split-gso by default’ patch, accepted to upstream, manually to our own cake repo for Toke to commit.  I note with some distress that there’s an ‘iproute2’ upstream patch pending to enable the userspace side of the same thing that currently is NOT in the ‘tc-adv’ repo.

Dare I also suggest that a man page update would be appreciated by iproute2-next too.

The above would make the ‘Cake for Openwrt’ maintainer very happy ;-)


Cheers,

Kevin D-B

012C ACB2 28C6 C53E 9775  9123 B3A2 389B 9DE2 334A


[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [Cake] CAKE related iproute2 & kernel patches - keeping things in sync

[Dave Taht]

On Sun, Jul 29, 2018 at 3:05 AM Kevin Darbyshire-Bryant
<kevin@darbyshire-bryant.me.uk> wrote:
>
> To whom it may concern (Dave) ;-)
>
> This is a general plea that when patches are submitted to upstream please can we also commit them to our current development repositories.

Mea culpa. I was hiding under my desk expecting the 10GigE+ world to
unite and march upon me, torches ablaze and, while gearing up for
battle there, collecting data on how bql and split-gso interacted at
various speeds, I didn't expect davem to just take the darn patch.

I have this whole lovely, giant, rant ,and plots that I'm not gonna be
motivated to finish now.

This does raise a long term point however in that as we go mainline
more tweaks and patches *will* arrive
via normal linux kernel processes from others. Do you want maintainership there?

> 4.19 isn’t even released yet, so most people, including Openwrt, get cake via our 'out of tree’ repositories.  This is also a good idea from a point of view of testing.  I appreciate the latest changes are of ‘one line’ type variety and so mostly harmless but ideally it should at least be in our own out of tree repo’s first/at the same time.
>
> I had to submit the latest ‘split-gso by default’ patch, accepted to upstream, manually to our own cake repo for Toke to commit.  I note with some distress that there’s an ‘iproute2’ upstream patch pending to enable the userspace side of the same thing that currently is NOT in the ‘tc-adv’ repo.
>
> Dare I also suggest that a man page update would be appreciated by iproute2-next too.

I started reviewing the man page's gobble of troff, started writing a
tuning section (and decided that needed a web page), went looking for
other missing keywords, and... we haven't heard from logan in a
while... my back is covered with black jube jells and dust bunnies
from hiding under my desk.

and I dunno, has anyone read the man page lately? There's a HUGE
opportunity to bikeshed there.


> The above would make the ‘Cake for Openwrt’ maintainer very happy ;-)
>
>
> Cheers,
>
> Kevin D-B
>
> 012C ACB2 28C6 C53E 9775  9123 B3A2 389B 9DE2 334A
>
> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake



-- 

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

Re: [Cake] CAKE related iproute2 & kernel patches - keeping things in sync

[Kevin Darbyshire-Bryant]

[-- Attachment #1: Type: text/plain, Size: 2614 bytes --]



> On 30 Jul 2018, at 00:42, Dave Taht <dave.taht@gmail.com> wrote:
> 
> On Sun, Jul 29, 2018 at 3:05 AM Kevin Darbyshire-Bryant
> <kevin@darbyshire-bryant.me.uk> wrote:
>> 
>> To whom it may concern (Dave) ;-)
>> 
>> This is a general plea that when patches are submitted to upstream please can we also commit them to our current development repositories.
> 
> Mea culpa. I was hiding under my desk expecting the 10GigE+ world to
> unite and march upon me, torches ablaze and, while gearing up for
> battle there, collecting data on how bql and split-gso interacted at
> various speeds, I didn't expect davem to just take the darn patch.

They’re gathering firewood….and petrol tankers :-)
Actually I too was pretty surprised to see it committed.


> I have this whole lovely, giant, rant ,and plots that I'm not gonna be
> motivated to finish now.
> 
> This does raise a long term point however in that as we go mainline
> more tweaks and patches *will* arrive
> via normal linux kernel processes from others. Do you want maintainership there?

Personally, Noooo! :-)  This sounds like backports territory.  And I’m back to that idea of dropping the kmod package and introducing cake via a kernel patch for openwrt.   *shudder*


> 
>> 4.19 isn’t even released yet, so most people, including Openwrt, get cake via our 'out of tree’ repositories.  This is also a good idea from a point of view of testing.  I appreciate the latest changes are of ‘one line’ type variety and so mostly harmless but ideally it should at least be in our own out of tree repo’s first/at the same time.
>> 
>> I had to submit the latest ‘split-gso by default’ patch, accepted to upstream, manually to our own cake repo for Toke to commit.  I note with some distress that there’s an ‘iproute2’ upstream patch pending to enable the userspace side of the same thing that currently is NOT in the ‘tc-adv’ repo.
>> 
>> Dare I also suggest that a man page update would be appreciated by iproute2-next too.
> 
> I started reviewing the man page's gobble of troff, started writing a
> tuning section (and decided that needed a web page), went looking for
> other missing keywords, and... we haven't heard from logan in a
> while... my back is covered with black jube jells and dust bunnies
> from hiding under my desk.
> 
> and I dunno, has anyone read the man page lately? There's a HUGE
> opportunity to bikeshed there.

Lord no, not the bikeshed!  I was more thinking of including the two new keywords that had been introduced….. not going wild   :-)

Kevin

[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [Cake] CAKE related iproute2 & kernel patches - keeping things in sync

[Loganaden Velvindron]

On Mon, Jul 30, 2018 at 7:07 PM, Kevin Darbyshire-Bryant
<kevin@darbyshire-bryant.me.uk> wrote:
>
>
>> On 30 Jul 2018, at 00:42, Dave Taht <dave.taht@gmail.com> wrote:
>>
>> On Sun, Jul 29, 2018 at 3:05 AM Kevin Darbyshire-Bryant
>> <kevin@darbyshire-bryant.me.uk> wrote:
>>>
>>> To whom it may concern (Dave) ;-)
>>>
>>> This is a general plea that when patches are submitted to upstream please can we also commit them to our current development repositories.
>>
>> Mea culpa. I was hiding under my desk expecting the 10GigE+ world to
>> unite and march upon me, torches ablaze and, while gearing up for
>> battle there, collecting data on how bql and split-gso interacted at
>> various speeds, I didn't expect davem to just take the darn patch.
>
> They’re gathering firewood….and petrol tankers :-)
> Actually I too was pretty surprised to see it committed.
>
>
>> I have this whole lovely, giant, rant ,and plots that I'm not gonna be
>> motivated to finish now.
>>
>> This does raise a long term point however in that as we go mainline
>> more tweaks and patches *will* arrive
>> via normal linux kernel processes from others. Do you want maintainership there?
>
> Personally, Noooo! :-)  This sounds like backports territory.  And I’m back to that idea of dropping the kmod package and introducing cake via a kernel patch for openwrt.   *shudder*
>
>
>>
>>> 4.19 isn’t even released yet, so most people, including Openwrt, get cake via our 'out of tree’ repositories.  This is also a good idea from a point of view of testing.  I appreciate the latest changes are of ‘one line’ type variety and so mostly harmless but ideally it should at least be in our own out of tree repo’s first/at the same time.
>>>
>>> I had to submit the latest ‘split-gso by default’ patch, accepted to upstream, manually to our own cake repo for Toke to commit.  I note with some distress that there’s an ‘iproute2’ upstream patch pending to enable the userspace side of the same thing that currently is NOT in the ‘tc-adv’ repo.
>>>
>>> Dare I also suggest that a man page update would be appreciated by iproute2-next too.
>>
>> I started reviewing the man page's gobble of troff, started writing a
>> tuning section (and decided that needed a web page), went looking for
>> other missing keywords, and... we haven't heard from logan in a
>> while... my back is covered with black jube jells and dust bunnies
>> from hiding under my desk.
>>

Will find time to update the man page :)



>> and I dunno, has anyone read the man page lately? There's a HUGE
>> opportunity to bikeshed there.
>
> Lord no, not the bikeshed!  I was more thinking of including the two new keywords that had been introduced….. not going wild   :-)
>
> Kevin

[Cake] man page bikeshed

[Dave Taht]

I would rather like the man page (one day) to include two realistic
examples - (say a week's uptime), taken while loaded,  one example
outbound, one example inbound, rather than the unloaded one it
currently has and the less than massively loaded one...

I loved looking over this result (at 40 users!) today.

https://forum.lede-project.org/t/sqm-cake-and-piece-of-cake-qos-high-cpu-usage/17794/2

Re: [Cake] man page bikeshed

[Dave Taht]

other stuff.

* gso-split no-gso-split not documented (what section do they belong in?)
* ingress/egress keywords not documented

I would like to bring out more that cake is a shaper that can also be
left unconfigured and run at line rate.

I honestly *didn't know* everybody else here wasn't using it that
way... it's my default qdisc on everything with spare cpu! dogfood it
via: sysctl -w net.core.default_qdisc=cake

"       CAKE  (Common  Applications  Kept  Enhanced) is a shaping-capable queue
        discipline which uses both AQM and FQ."

is a bit weak.

"       CAKE  uses  a  deficit-mode  shaper, which does not exhibit the initial
       burst typical of token-bucket shapers.   It  will  automatically  burst
       precisely  as  much  as required to maintain the configured throughput.
       As such, it is very straightforward to configure."

I have fiddled with the metro setting for local lans. at a gbit, the
results are "interesting" as a local qdisc,
at 100 flows, we end up with full throughput, 70k of buffering, 40k of
bql, tons of marks, bunch of drops in the
switch (which is like 192k of buffer there), and short rtts and lots
of retransmits. cwnd is capped too much.

(the sch_fq alternative is like 1.7MB in size and I haven't tried to
compare the two)

Or maybe that was a 500 flow result. Can't remember just now.

On Mon, Jul 30, 2018 at 10:23 AM Dave Taht <dave.taht@gmail.com> wrote:
>
> I would rather like the man page (one day) to include two realistic
> examples - (say a week's uptime), taken while loaded,  one example
> outbound, one example inbound, rather than the unloaded one it
> currently has and the less than massively loaded one...
>
> I loved looking over this result (at 40 users!) today.
>
> https://forum.lede-project.org/t/sqm-cake-and-piece-of-cake-qos-high-cpu-usage/17794/2



-- 

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