Unlikely, the run time cost of SQM is caused by the qdisc that are exercised, while most changes affect how SQM configures and starts these qdiscs... So not impossible, but rather unexpected. I would wonder more about the receive side scaling setting. What does:
for file in /sys/class/net/*
do
echo $file RX rps_cpus
cat $file"/queues/rx-0/rps_cpus"
echo $file TX xps_cpus
cat $file"/queues/tx-0/xps_cpus"
done
show?
Nope, that is IMHO solid release engineering, if a bug can be safely worked-around, but progress on fixing it has stalled it seems better to get the release out instead of waiting longer for Godot... Yes, unfortunate for users that use that functionality, and hopefully a fix can be found. But the alternative of delaying the release even further seems far worse. This is of course just my subjective opinion, others might disagree.
Well, the alternative is everybody "skipping"/not getting this release and actually testing it under real life conditions on a varied set of devices and configurations. IMHO the final steps of release maturation require a decent deployment, which for an opensource project like OpenWrt more or less means cutting a release to recruit sufficient many "testers". (Ideally everything with a release just works perfectly, but bugs happen)
There is already some described fix for offloading. If you want to speed up fix just test it yourself @Router and give feedback:
http://lists.openwrt.org/pipermail/openwrt-devel/2021-August/036223.html
Odd, none of the changes between https://github.com/tohojo/sqm-scripts/commit/bb064ad6065dcfb4966662bfab15b9fcdbb48e5f (1.5.0) and https://github.com/tohojo/sqm-scripts/commit/5d7e7977e14e147d5bcfa8a5f01636c7ab230fa4 (1.5.1) really should make any difference at run time...
Could you post the output of tc -s qdisc for both versions by any chance and if you are at it also the output of
SQM_DEBUG=1 SQM_VERBOSITY_MAX=8 /etc/init.d/sqm stop ; SQM_DEBUG=1 SQM_VERBOSITY_MAX=8 /etc/init.d/sqm start
That might help figuring out what is happening here.
In programmers' language, versions are named
RC4 is supposed to have a few bugs remaining, and these have been solved in the stable.
Meow! 
Upgraded 5 Meraki MR-24's, keeping settings. One had been running 21.02.0-rc2 since June, the others were still on 19.07.07. Touched LUCI Network->Interfaces page on these latter 4 to trigger auto-migration of bridge and ifname configurations.
Everything working perfectly after a day. Many thanks devs!
I have a very bad situation with 21.02.0 on ASUS RT-AC57U. Something is wrong with the network connection. Delays and speeds are insanely bad. I barely can open any website, speedtest struggles to even start, and opkg update can't sync packages because of connection corruption / timeout.
Hardware is not overloaded or so, CPU usage is nearly zero and RAM has almost 100 MB free. No clues in the logs.
I've tried to tweak all the possible settings, hopped back and forth to 19.07.8 (with full reset) several times to be sure that this is firmware issue. And yeah, the result is: 19.07.8 works excellent, 21.02.0 is unusable.
Can only suggest that maybe the DSA works wrong on this hardware? No other ideas.
Edit: I found the issue. The only suspicious setting I was forced to use: MAC override.
Override is needed for auth to my ISP. I just tested through the other router and yes: it causes all this trouble. Without override the connection works perfect. But with this option set connection became unsuable.
So this is kinda a bug report now. 
I managed it by using the ubuntu keyserver
$ gpg --keyserver keyserver.ubuntu.com --recv-keys 88CA59E88F681580
gpg: key 88CA59E88F681580: "OpenWrt Build System (PGP key for 21.02 release builds) <pgpsign-21.02@openwrt.org>"
That would only make sense for project actually having release cycle in place (every month or year instead of "when it's ready").
Look at it this way. I'm a C7 V2 user who needs flow offloading and IPv6. There's really two possible outcomes.
For those affected it's the same result either way, except in option 2 at least those who don't need the feature can use the new release.
Mmmh, one way of looking at that. Then again OpenWrt aimed at 1-2 releases per year, and we are at least at 1.5 years since the last release already.... So 'when it is ready' is not OpenWrt's actual goal, it just happens to look like that....
And do we wait to long then all the other packages gets to old.
Like OpenVPN got updated to include with TLS1.3 and EC a long time ago but OpenWRT got stuck with the old version in 19.07.
Not to mention the actual kernel. 21.02 has the 5.4 kernel but at release time the world started using the 5.10. As far as I understand there where actual thoughts to upgrade to 5.10 before rc1 but that idea was scraped. But as fast as the branch was released i February then the master got upgraded.
To be honest I think 21.02 will live fast and die young. But with the new DSA it is a must release to get it working into the future…
Hm. Wireguard cannot be installed in my Archer C7, because "kmod-wireguard ist not available in any repository."
Does anybody know a solution? Or do i just have to wait because that kernel module package is not uploaded yet?
Can you show the exact commands and error messages that you are using when trying to install it (from SSH console)...
making it 21.02.0 / config-network-device aware might be good start...
The problem with WDS is still there.
https://bugs.openwrt.org/index.php?do=details&task_id=3961
I'll stay with RC3 till will be fixed. Thanks for your efforts
Did not work on my WRT3200ACM. WLAN not working, several issues. I reverted to 19.07.8.
OK. That's strange...
Installation via SSH works and wireguard is up and works.
It is just the installation via luci web interface which fails. Here is a screenshot:
mjpg-streamer DOES NOT WORK with OpenWrt's latest 21.02 update!
The router is NBG6617 and here's my topic about this annoying issue.
Help!
Seems 21.02.0 is a bust for WRT3200ACM!
I have run my WRT's in dumb AP mode for years, basically following: https://openwrt.org/docs/guide-user/network/wifi/dumbap
I have been testing 21.02.0rc's and the first official release on my spare WRT1900ACv1 in dumb AP mode without any problems.
UPGRADE METHOD
WHAT WORKED
WHAT DOES NOT WORK
CONCLUSION
