Let's start by making the EU-300 the wan, then re-visit the CPU load issue and then re-evaluate whether the pi under OpenWrt works well enough, or not...
Regarding the CPU:
install htop and configure it to show the detailed CPU time (IIRC htop will not show soft interrupt processing otherwise, but that is where qdiscs like cake are accounted fir), then run htop on the OpenWrt router parallel to capacity tests and look whether any CPU is clogged by too much SIRQ (in the per CPU bar graphs this is shown as pink or purple) if the CPU load approaches 90% you likely have an issue. Then enabling packet steering might help or manually assigning and pinning interrupts... but first figure out whether we actually see CPU overload...
As you're using snapshot, be aware that there are 2 modes for packet steering - '1' is the newer method introduced in snapshot, and '2' is the method used in 23.05 and earlier. Test both, as the old method ('2') can have better performance.
The amount of cpu required depends on the amount of traffic.... to test whether sqm works try setting the shaper rates for both directions to 100 Mbps and run a online test....
If wired sqm seems to help but not over WiFi I would guess that likely your WiFi is the bottleneck... and bufferbloat is mostly dependent on the bufferibg/queueing at the bottleneck link. The whole idea behind sqm's traffic shaping is to make sure the effective bottleneck is on the sqm node so sqm's AQM (active queue management) and traffic scheduler are in control...
I belive i should open another thread to chase this down?
My main concern is my AP is underpowered to do SQM, Since the RPI will handle WAN side and the AP only needs to do SQM on wlan, would that make it's life easier?
### check airtime fairness / AQL support on OpenWrt:
https://forum.openwrt.org/t/crowd-sourcing-the-wi-fi-chip-info/193862
ubus call system board | grep 'model\|description'
iw list | grep 'Wiphy\|TXQS\|AIRTIME_FAIRNESS\|AQL'
iwinfo | grep 'Hardware:\|PHY name'
on your AP... that will give us the capabilities (these should handle download traffic reasonably well, but upload is under control of the stations...)
The point is that for WiFi fq_codel really should be part of the WiFi stack and made to operate well with the variable rate nature of WiFi...
Well, I would recommend to use ethernet for truly latency sensitive stuff like remote desktop or on-line gaming...
So here is the rub, under saturating loads fq_codel and cake will actually allow the standing queue to rise of to target and that will show in the average RTT increase, so with the default target of 5ms the average RTT should also increase by ~5ms, and hence if a bufferbloat test returns the average RTT increase you need to expect around +5ms in each direction... with WiFi adding more variability.
Your choice, after it is your thread, however you are likely to attract more eyes/help if you post a new thread with a title fitting your actual question.
It isn't on openwrt right now, as I am worried about unnecessarily fiddling with it and finding out the device doesn't support SQM. It's a Archer AX23 with dual core 880MHZ MT7621DAT soc and present in the openwrt wiki
That pretty much means that none of the OpenWrt WiFi goodies are implemented...
As I said for WiFi you really want to move fq_codel into the AP where it does not need a traffic shaper and hence is considerably cheaper...
So installing OpenWrt seems at least an option... but the dual core MIPS CPU is not going to be fast...
But given: Warning 05/2024 There is no confirmed way to revert to OEM firmware at the moment. Do not proceed with installation, if not sure. Check the forum discussion.
you really need to be certain you are willing to risk switching to OpenWrt, assuming you have the V1 version to begin with...