Respectfully, I think sqm-scripts might take the "configure the required tc action ctinfo" part and maybe the "required nftables bits to store the egress DSCP into the conntrack database" but anything beyond that is IMHO clearly outside sqm-script's wheelhouse...
Yes, that’s what I was thinking when I mentioned “generic”, but didn’t mention any specifics. After Qosify, DSCPClassify, QoSmate, and others, the market for such scripts is saturated (IMHO). Getting the basic ctinfo mechanism into sqm-scripts will allow people to setup regular fw4 rules to mark traffic with DSCP for basic usage.
Thanks for the feedback, that makes sense and I agree with most of it.
My goal with this project was not to propose yet another competing QoS framework, nor to replace existing solutions like qosify, QoSmate, or fw4-based setups.
What I was trying to address is a slightly different angle:
• SQM (and luci-app-sqm) is already widely installed and familiar to many users
• Many users are uncomfortable writing custom nftables or fw4 rules
• There is often no easy way to observe whether DSCP markings actually survive end-to-end and are honored by CAKE
The custom SQM script and LuCI additions are therefore meant as a simple, opinionated workflow:
• define a small set of latency-sensitive endpoints (IPv4/IPv6)
• apply DSCP in a controlled way
• immediately validate the result via a read-only conntrack view
I fully agree that the generic ctinfo mechanism (store egress DSCP into conntrack and restore on ingress) could be useful as a reusable building block, possibly within sqm-scripts, while higher-level policy logic and UI probably belong outside of it.
For now, this project is mainly intended as:
• a learning and experimentation tool
• a reference implementation of ctinfo + DSCP + CAKE
• a convenience layer for users already relying on luci-app-sqm
I appreciate the discussion and pointers they help clarify where this fits in the broader ecosystem.
Just a quick update since the last discussion. I continued experimenting with the idea and added a few improvements that might make the setup easier to test and reproduce.
Recent changes include:
• optional CAKE multi-queue (cake_mq) support for multi-core hardware
• improved DSCP classification pipeline using nftables prerouting for download traffic
• optional ctinfo DSCP restore from conntrack
• separate UDP and TCP priority classification
• improved installer with automatic opkg / apk detection (OpenWrt 24.x / 25.x)
• a small LuCI view to observe active DSCP connections in real time
The goal is still not to compete with qosify or QoSmate, but rather to provide a simple way to experiment with ctinfo + DSCP + CAKE inside the familiar SQM workflow.
It also serves as a small reference implementation showing how nftables DSCP marking, conntrack storage and ctinfo restoration interact with CAKE.
The project is available here if anyone is interested in testing or experimenting with it:
