Page MenuHomeVyOS Platform

Cake and FQ-PIE
Closed, ResolvedPublicFEATURE REQUEST

Details

Version
-
Is it a breaking change?
Unspecified (possibly destroys the router)
Issue type
Feature (new functionality)

Related Objects

StatusSubtypeAssignedTask
ResolvedFEATURE REQUESTc-po
ResolvedFEATURE REQUESTc-po
ResolvedFEATURE REQUESTc-po

Event Timeline

syncer triaged this task as Wishlist priority.

I've attempted to backport the CAKE patches accepted into net-next for the VyOS kernel here: https://github.com/Lochnair/vyos-kernel/commits/linux-vyos-4.14.y
I've gotten it to the point that it compiles, but I haven't tested to see if I accidentally broke anything. Partly because I haven't had the chance to look at backporting the tc stuff yet.

Is this stuff upstream? If so, we could also upgrade to 4.18, the save the backporting trouble?

We could also compile it as module (if supported) same we do for wireguard.

CAKE is upstream, but it didn't make it into 4.18, so it's currently only in master. To be fair it's easy enough to backport for 4.14, most of it is small changes.
Also I thought you'd prefer to stay on a LTS kernel, thus the backporting attempt.

And yes they do have an out-of-tree repository, so we could just use that.
It's just my personal preference to avoid out-of-tree modules whenever possible.

Edit: Even if we used the out-of-tree repo, we'd still have to backport the iproute2 patches.

Thx for the info. Yeah it's a per person choice if in-tree is preferred over out-of-tree.

For VyOS we already have a modular Kernel (for now) IMHO it's easier for an out of tree module (besides a new CI job + repository) b/c it will become beneficial on Kernel upgrades to later versions (less patches to port).

I'm fine with every implementation right now as it's your contribution (THX by the way)!

Hrrmf, 'twas more painful to get the iproute2 patches right than I'd hoped. Not sure how much effort I should spend getting the patches to apply, or if we should just bump to 4.18.
Apart from the kernel headers in the iproute2 tree, everything works as-is that way.

Upgrading to 4.18 should not take more then two hours incl. Iproute2 for me. Should we give it a try? Then I prepare an ISO

Might as well if you're up for it :)

For iproute2 we need these patches:
https://git.kernel.org/pub/scm/network/iproute2/iproute2.git/commit/?id=714444c0cb262e2c2a8d7398e3649c9b84666df0
https://git.kernel.org/pub/scm/network/iproute2/iproute2.git/commit/?id=77c9fbd06e1350e14d3b565d9d5beb0c5af692bf
https://git.kernel.org/pub/scm/network/iproute2/iproute2.git/commit/include/uapi/linux/pkt_sched.h?id=8b099da560d654682ed9e0a46e93046b642e9c2b
https://git.kernel.org/pub/scm/network/iproute2/iproute2.git/commit/?id=23a67b008aea05992eb5b5c24c76e38c3ca7074a

Kernel patches:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=046f6fd5daefac7f5abdafb436b30f63bc7c602b
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7298de9cd7255a783ba93533acbf1c2b0a9c582d
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8b7138814f29933898ecd31dfc83e35a30ee69f5
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b60a60405fb95a688eb2ef4ef20f5fcaa7b64f68
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ea82511518f4f2e5fe83d2fe1884ef5fc6be6204
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=83f8fd69af4f62136765b60fd0efa1c9167917c5
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a729b7f0bd5bf4919306556aed614438f5174537
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0c850344d3882886f842bf0b50a9ff23001adb7e

I've also started thinking about the template:

traffic-policy {
    cake cakepolicy {
        bandwidth 10mbit
        direction egress
        flow-isolation dual-srchost
        memlimit 4096000
        nat-lookup enable
        overhead 32 atm
        priority-queue diffserv4
        rtt 100ms
        split-gso enable
        wash disable
    }
}

Please have a look at the man page to see what we need to include: https://dl.lochnair.net/Bufferbloat/Cake/tc-cake.8.html
Part of the challenge is that CAKE has a lot of keywords for ease-of-use. For example on my connection bridged-llcsnap is the right keyword to use, but it's actually just a shortcut for overhead 32 atm.
Similar issues for bandwidth, where you can either have 10mbit, unlimited or autorate-ingress. I'm not familiar enough with either the old template system, or the new XML one to know how to best represent this.

@Lochnair see branches at:

https://lwn.net/Articles/762566/ states:

The CAKE queuing discipline, which works to overcome bufferbloat and other problems associated with home network links, has been merged.

ISO (with Kernel 4.18 and iproute2 4.18) can be found here at 11:30 p.m. CEST (UTC +2):

cpo@LR1:~$ uname -a
Linux LR1.mucI.mybll.net 4.18.0-amd64-vyos #3 SMP Mon Aug 20 21:32:31 CEST 2018 x86_64 GNU/Linux
cpo@LR1:~$ sudo modprobe wireguard
cpo@LR1:~$ dmesg | tail -n 3
[  180.114930] wireguard: loading out-of-tree module taints kernel.
[  180.115868] wireguard: WireGuard 0.0.20180708-1 loaded. See www.wireguard.com for information.
[  180.115869] wireguard: Copyright (C) 2015-2018 Jason A. Donenfeld <Jason@zx2c4.com>. All Rights Reserved.
cpo@LR1:~$ ip -V
ip utility, iproute2-ss171113
In T725#18039, @c-po wrote:

Nice work!

https://lwn.net/Articles/762566/ states:

The CAKE queuing discipline, which works to overcome bufferbloat and other problems associated with home network links, has been merged.

I'm well aware that it's been merged, but we still won't see it in a release before 4.19 is released mid-October.

ISO (with Kernel 4.18 and iproute2 4.18) can be found here at 11:30 p.m. CEST (UTC +2):

cpo@LR1:~$ uname -a
Linux LR1.mucI.mybll.net 4.18.0-amd64-vyos #3 SMP Mon Aug 20 21:32:31 CEST 2018 x86_64 GNU/Linux
cpo@LR1:~$ sudo modprobe wireguard
cpo@LR1:~$ dmesg | tail -n 3
[  180.114930] wireguard: loading out-of-tree module taints kernel.
[  180.115868] wireguard: WireGuard 0.0.20180708-1 loaded. See www.wireguard.com for information.
[  180.115869] wireguard: Copyright (C) 2015-2018 Jason A. Donenfeld <Jason@zx2c4.com>. All Rights Reserved.
cpo@LR1:~$ ip -V
ip utility, iproute2-ss171113

Not that I've tested it "properly", but your ISO seemed to work fine in a VM I fired it up in.

I've opened PRs against vyos-kernel and vyatta-iproute with the CAKE patches. I'll try to build an ISO with these patches included later.

@Lochnair any chance you can translate this into Linux tc syntax?

Is there a patch to include configuration for this out there somewhere yet? I'd be interested in testing it out; can possibly help with the patch if it's started too.

Unknown Object (User) subscribed.Jun 10 2020, 8:39 PM
Viacheslav set Is it a breaking change? to Unspecified (possibly destroys the router).Feb 5 2021, 9:31 AM
Viacheslav edited a custom field.
c-po removed c-po as the assignee of this task.May 29 2021, 9:01 PM
dmbaturin set Issue type to Feature (new functionality).Sep 3 2021, 12:07 PM

I'd like to see cake in vyos as well. I don't think this has been implemented yet (at least not under the traffic-policy section in 1.4-rolling) ?

I can take a look at this in the next few days, is it still feasible to write this in pearl? Or is there a planned rewrite of the vyatta-cfg-qos repo to python?

Unknown Object (User) subscribed.Feb 15 2022, 9:18 AM

Hi @hensur , I'm sure that this code should be moved to python implementation, patches for the legacy vyatta-cfg-qos will be rejected.
First of all, need to create CLI XML definition
https://docs.vyos.io/en/equuleus/contributing/development.html?xml-used-for-cli-definitions#xml-used-for-cli-definitions
and then create backend in python to process CLI commands
https://docs.vyos.io/en/equuleus/contributing/development.html?xml-used-for-cli-definitions#configuration-script-structure-and-behaviour

syncer changed the task status from Open to In progress.Oct 18 2022, 2:52 PM
c-po edited projects, added VyOS 1.4 Sagitta; removed VyOS 1.3 Equuleus (1.3.3).