I agree. MT7981 should fit a lot of use cases with expected cake performance at least at 400 Mbps when the end price for the complete device as wireless router solution will be around 100 USD.
I have better user experience under load with SQM. MT7981 should be a good fit for both configurations, with hardware flow offload enabled or without with SQM enabled.
I am weirdly pleased so many care about cake + the openwrt one. I would like (us) to make a concerted effort to make it scale better to this multicore. I have been thinking about ressurrecting IMQ in particular.
Briefly reading through it.
"Eero appears to have beaten them in their Wifi6 product."
Trust me they haven't. SQM on Eero wifi 6 products is a complete mess.
One thing while I have you here. I've always been puzzled about this. All these SQM algorithms seem to hate software based bandwidth limiters. There's something about the way they limit bandwidth that completely bamboozles the likes of cake and to some extent fq_codel. You'll get ridiculous jitter spikes. Maybe it's something to consider for CakeMQ on how to handle it. A whole network can be grinded to a halt if someone decides to limit bandwidth. Quite annoying.
I see this document was posted around August so you weren't to know but some later supported OpenWRT routers can now easily do Cake at over 2 Gbps. Most notably the MediaTek MT7986. The 500Mbit scaling problem mentioned isn't much of a problem going forward unless people want to stick to non wifi 6 devices for years... so maybe it is still worth looking into. 
I would differentiate between the hardware project to get the idea OpenWrt One to market as soon as possible and improving cake to better scale on multi core hardware.
While I would like to have both: the multi core router selling on the market with multi threaded cake reaching more than 400 Mbps I think working on both ideas should be decoupled.
As a side note: a preview of what OpenWrt One could be is available today: https://openwrt.org/toh/gl.inet/gl-mt3000
GL-MT3000 is based on MT7981, too. With 2.5 Gbps WAN and one Gigabit LAN port, but with 512 MiB memory.
GL-MT3000 MT7981 is supported and working:
I understand why such a barebones device was selected for 2024 - as this device will be used in many counties where $100 is considered very expensive for a home or small business firewall, and where current internet access speeds are in dozens or hundreds of Mbps and not even close to 1 Gbps. Such a Low-end device needs to exist in 2024 for those setups.
However, I would like to propose that another - more powerful - device be also released as a standard OpenWRT hardware offering. Here’s my suggestion:
Minimum specs:
This is why I think that the hardware platform that you guys selected is barebones and insufficient in specs for 2024 for more complex deployment scenarios.
Inter-VLAN routing done by OpenWRT. This is definitely a must for a hardware platform in 2024 to provide firewall-protected inter-VLAN routing. Therefore, the LAN interface must be at least 2.5 GBPs to account for a moderate amount of inter-VLAN-routed traffic in a Gigabit network. Some of this traffic would be inter-VLAN routed and some would be internet-bound. So, with the platform you chose, your Internet-facing port must be 1 Gbps, which is fine for maybe 95% of the world today but this is not forward looking whatsoever. There needs to be another more powerful official OpenWRT hardware platform that can take Internet connectivity above 1 GBPs. Personally, I think a more powerful platform should have two 2.5 Gbps interfaces for the dual Internet connectivity and a 5 GBPs interface facing the LAN switch for Inter-VLAN routing plus Internet-bound traffic. But, if this is too expensive or not yet available from the hardware perspective, the minimum that this more advanced hardware platform should have is two 2.5 Gbps interfaces (one for the primary WAN and one for the LAN) and one 1 Gbps interface for the secondary WAN).
There is no need to have a Wi-Fi chip in this more advanced official OpenWRT hardware platform because it would be used in larger residences or small business settings where dedicated APs are required to provide proper Wi-Fi coverage. It would suggest not including a Wi-Fi feature into this platform at all.
4 GB or RAM and 8 GB of storage is required to run additional official packages without negatively affecting the routing performance.
Thanks.
My dream device is so different from most. For the global south, cost is paramount, and driving down the cost of fiber (PON). There is an excellent Huwai device I have seen that is wireless-n, fq_codeled, all over Nicaragua, that convinced me that LibreQos was not needed there - but in Columbia. Next up is reliability and longevity - but neither of those are my priorities for my dream device.
I would love to see a quad-core A53 derivative with 64MB of onboard RAM, heck pure SRAM + no cache, or failing that, an increase in size of the icache and dcache, and while I am dreaming, an entirely separate memory area for dcache and icache in interrupt mode... Anything that can make an inorder processor fly, and behave predictably.
A single chip, 4 antenna wireless-n router. wifi started getting even crazier stupid ideas in it after that. An arm amulet successor with such low self noise as to eek another few db from the wireless signals, and fit in your watch.
Coupled power and rate control to lower power also...
... even smaller but far more capable than the rather lame esp32 chips.
Anyway... back to reality. (one big reason I am so enthused about the one project is OH! a Raspi with GOOD wifi!! Who'd have thunk it)
To use any internet service faster than 1 gigabit you need a 2.5 gigabit WAN port and at least one 2.5 gig LAN port. If I need more than one LAN port, I can add a switch. If the hardware only supports 1 gigabit on LAN (or WAN) then I have to replace the whole router.
Also, you need at least three ethernet ports to run dual WAN.
The GL-MT6000 has two 2.5 gig and four one gig ports for $160 on Amazon.
An M2 slot that would take a WIFI card would allow you to add 6GHz support.
This project is not a top performance router but opensource device for learning about networking in openwrt and for some enthusiasts. Fir top performance router there are different targets.
Agreed.
I have the MT3000 and it's amazing. Even on the gli fork.
What device was that? The Huawei ONTs installed by most FTTH ISPs in South America (because are cheap and the OLTs are also made by Huawei) have terrible bufferbloat.
PD: my bufferbloat got improved to B after my ISP upgraded my plan to 300mbps so I think it has to do something with the shaping done on these devices 
I've had some time to read about this here and i'm thinking that this is pointless since we have alot of whole kind devices and we don't need another electro garbadge of which maybe fifteen enthusiast will have some fun for a few weeks and later it will land in garbadge bin. Better to focus on maintence this unwanted part of code to workaround some things that noone want to rewrite new.
What is the benefit of assimmetrical ethernet speed connectors?
2.5gbe in, 1gbe+ wifi for internal network?
or
1gbe in, 2.5gbe + wifi for internal network?
I would recommend 2.5gbe in and out
I had tested a 100 and 10Mbit PON device, and it was clearly fq_codeled. I had also heard that Nicaragua "had good wifi" compared to "country X, Y, Z". My bufferbloat journey started there - and we tested fq_codel and cake extensively in SJDS - so i hope the national provider had figured this out! (I tested 3 different locations with very good results, at 10 or 100mbit). The WiFi on two of them was clearly NOT fq_codeled, tho.
The MT7981 SoC already has integrated 2.4 and 5ghz WLAN. I’m curious why it’s needed to also include MT7976C? Wouldn’t a single chip solution lower cost?
Seems like some devices like the Cudy WR3000 and Zyxel NWA50AX Pro only use MT7981 for WLAN. The Zyxel even has 3x3 in 5Ghz
2.5gb could be connected to a managed switch with multiple vlans
Yes, but then we need additional switch which duoble up costs and we have this kind of things already on market.
So far, you've been the only one that's mentioned this concern in the forums. Haven't read it anywhere else. On the One announcement, OpenWRT mentioned they wouldn't be the ones manufacturing nor distributing the hardware. Maybe some OpenWRT devs will place a tad extra attention to making sure OpenWRT plays nice with their hardware, and some of their time will go into keeping the hardware up-to-date in subsequent iterations, but apart that, I don't see any downsides from the One announcement itself.
Is there a risk in general that an open source software splits and becomes a paid service... sure, but that's just a risk for any project really, even paid services split and to become another paid service. But so far there doesn't seem to be any movement from the developers/community to do so... but please feel free to post any evidence of the contrary. Anything else is just pure speculation.
Here's another speculation which I think has a little more evidence---20 years from now OpenWrt will celebrate their 20th anniversary of producing an open source hardware, and their 40th anniversary of OpenWrt, still with an active community.
Oh, just buy a Turris Omnia already! Good 8y old hardware that still kicks a$$, not a chinese ewaste crap obsolete next year.
Better for anniversary to simply buy sources from broadcom for wireless drivers.