Qosify: new package for DSCP marking + cake

My next question is how to install qosify.

I'm currently OpenWrt 21.02.0-rc2 on a Raspberry Pi 4.

qosify doesn't appear as an available package. I've also spun up a VM running 21.02.3 and it isn't available on that machine either.

Is qosify only available in certain builds?

22.x and master

1 Like

This is how i installed qosify on my wrt32x about a month ago not sure if there is an updated version or not though...

wget https://downloads.openwrt.org/snapshots/targets/mvebu/cortexa9/packages/qosify_2022-04-08-ef82defa-1_arm_cortex-a9_vfpv3-d16.ipk

opkg install qosify_2022-04-08-ef82defa-1_arm_cortex-a9_vfpv3-d16.ipk


just change the path to your firmware version...

Is it easy to set up qosify to ONLY mark packets and not do anything else?

I am a total noob, but following the examples in this forum I have been able to configure qosify successfully and without knowing how to test it thoroughly or how it works at all, my impression is that it is very simple to configure and that it works quite well.

Is it possible that there is something to make adaptive bandwidth work with qosify?

I would like to think so.

The below may reflect a lack of understanding on my part. But based on my limited understanding, I share the following thoughts.

Qosify describes itself in the following way:

QoSify is simple daemon for setting up and managing CAKE along with a custom eBPF based classifier that sets DSCP fields of packets.

I'm hopeful qosify doesn't force you to set up CAKE such that CAKE can be set up manually and rates adjusted manually outside qosify.

Perhaps qosify would be better off just being markify to mark packets rather than this potentially awkward mix of trying to combine application of CAKE and marking which will presumably not work for cases like mine where I have VPN pbr and need to manage my own ifb (via hotplug for when VPN goes down and back up) and settings to make upload and download get handled correctly despite mix of encrypted and unencrypted flows over the last mile connection I need to control.

Since it's not applying CAKE that's hard. That can be done easily using scripts or the sqm tools in OpenWrt.

The value add is facilitating marking without horrible netifd scripting which to me looks like a total mess.

So that's why I'm wondering if qosify ought to be split up into separate components or just handle the marking aspect.

It’s a perfect total solution for 99% of users looking for QoS. You edge case is not reason enough to make it more complicated for the 99%, in my opinion.

The application of CAKE has been solved with existing OpenWrt solutions. That's never been a complicating issue for users. What has been a complicating issue is DSCP marking. The latter was the missing part that needed attention.

I think it's just the design choice that I struggle to wrap my head around because it seems like DSCP marking apart from applying CAKE makes sense. Aren't there times you'd want DSCP marking without necessarily even wanting CAKE at all?

It's like having one tool to offer a wine glass and better bottle opener in one when wine glasses were already working well. There seems to be something nice in my mind about having separate discrete tools for different jobs.

In any case, at the very least is it possible to just use qosify to DSCP mark without it managing CAKE for those who just want the DSCP marking aspect of qosify and not the CAKE aspect of qosify?

1 Like

Tagging without sqm can make sense, think of a campus network with QoS on the switches (even cheap smart-managed L2 switches do offer that).

1 Like

It should not be hard to change this to simply not emit the tc calls that instantiate the qdiscs.
Say either by supplying -1 as rate (0 is a legitimate rate for cake indicating "unlimited", which can make sense in specific conditions) or by adding a new control variable to enable/disable cake.

1 Like

The qosify tagging (adding the bpf filter) is still relative to the interface where CAKE will be instantiated. So they can’t be too decoupled otherwise you may not be tagging the traffic before it enters the qdisc.

There’s nothing preventing the autorate script from changing CAKE bandwidth even if qosify is in use.

root@router:~# tc filter show dev eth1 egress
filter protocol all pref 272 bpf chain 0 
filter protocol all pref 272 bpf chain 0 handle 0x1 qosify_egress_eth:[*fsobj] direct-action not_in_hw id 4 tag 9638cd99f888e843 jited 

root@router:~# tc filter show dev eth1 ingress
filter protocol all pref 272 bpf chain 0 
filter protocol all pref 272 bpf chain 0 handle 0x1 qosify_ingress_eth:[*fsobj] direct-action not_in_hw id 9 tag 9638cd99f888e843 jited 
filter protocol ip pref 273 u32 chain 0 
filter protocol ip pref 273 u32 chain 0 fh 800: ht divisor 1 
filter protocol ip pref 273 u32 chain 0 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:1 not_in_hw 
  match 00350000/ffff0000 at 20
        action order 1: mirred (Egress Redirect to device ifb-dns) stolen
        index 1 ref 1 bind 1

filter protocol 802.1Q pref 274 u32 chain 0 
filter protocol 802.1Q pref 274 u32 chain 0 fh 801: ht divisor 1 
filter protocol 802.1Q pref 274 u32 chain 0 fh 801::800 order 2048 key ht 801 bkt 0 flowid 1:1 not_in_hw 
  match 00350000/ffff0000 at 20
    offset plus 4 
        action order 1: mirred (Egress Redirect to device ifb-dns) stolen
        index 2 ref 1 bind 1

filter protocol ipv6 pref 275 u32 chain 0 
filter protocol ipv6 pref 275 u32 chain 0 fh 802: ht divisor 1 
filter protocol ipv6 pref 275 u32 chain 0 fh 802::800 order 2048 key ht 802 bkt 0 flowid 1:1 not_in_hw 
  match 00350000/ffff0000 at 40
        action order 1: mirred (Egress Redirect to device ifb-dns) stolen
        index 3 ref 1 bind 1

filter protocol ipv6 pref 276 u32 chain 0 
filter protocol ipv6 pref 276 u32 chain 0 fh 803: ht divisor 1 
filter protocol ipv6 pref 276 u32 chain 0 fh 803::800 order 2048 key ht 803 bkt 0 flowid 1:1 not_in_hw 
  match 00350000/ffff0000 at 40
    offset plus 4 
        action order 1: mirred (Egress Redirect to device ifb-dns) stolen
        index 4 ref 1 bind 1

filter protocol all pref 277 u32 chain 0 
filter protocol all pref 277 u32 chain 0 fh 804: ht divisor 1 
filter protocol all pref 277 u32 chain 0 fh 804::800 order 2048 key ht 804 bkt 0 flowid 1:1 not_in_hw 
  match 00000000/00000000 at 0
        action order 1: mirred (Egress Redirect to device ifb-eth1) stolen
        index 5 ref 1 bind 1

By this you mean that you want to tag before you apply CAKE right? But tagging and applying CAKE are different things and you may not want to do both on the same device right?

You want to tag the traffic before it enters the qdisc for the benefit of CAKE tins, or HTB classes, etc. Much like your original concern long ago, if you’re using a VPN on the router, tagging on the WAN interface doesn’t make sense if the outgoing traffic is already encrypted. So trying to separate tagging and tinning can get complicated.

My own network is not complicated, so that’s why I appreciate Qosify for what it is.

Just one question - If using DSCP markings, is there any need to enable NAT and host isolation?

These are orthogonal IMHO. Cake in its diffserv modes can use different DSCPs to steer a packet into its 1, 3, 4 or 8 priority tiers. In side each of these tiers it will then apply the isolation mode requested...
If you are fine with pure per-flow-fairness (individually in each tier) you need neither the nat nor the isolation keywords, if however you still want per-internal-host fairness you will need the isolation keywords. The nat keyword technically is only required if, like in the default configuration with cake on the wan interface, the packets do not yet/anymore carry the post/pre-NAT internal IP addresses.

Good point. For ingress traffic just using the true wan interface should work however, egress is tricker as the marking need to change before the egress qdisc handles a packet.

1 Like
  • how would I know? which is not eth0

ifstatus wan | grep -e device or just ifstatus wan if you want more detail.

or scripted way use /lib/functions/network.sh functions like network_find_wan, network_get_device etc