Just wondering if the NanoPi R6S needs irqbalance today on openwrt. I remember a cpu affinity file fix was needed a couple years back. But I’m wondering if there’s any tweaking to do now since openwrt is officially supported on the NanoPi R6S
Test it, compare the performance figures for all combinations.
Really, there is no shortcut to testing it. In theory, irqbalance should always work - in practice, it needs to know the ARM platforms quite well not to mess up (big-little, not lumping all on one core, etc.), 'should work', but often enough doesn't (well enough) on ARM.
Should I test using htop while running a speed test?
htop, iperf3 andkeeping an eye on the interrupt assignments.
So I tested and without irq balance it loaded mostly the last 4 cores of the R6S. Installed irqbalance and ran it again and it looks like mostly the first four cores are being loaded with maybe 2-3 of the last cores being lightly loaded.
This commit from March 2025 may be of interest. Assuming the last cores are the big cores and the first cores are the little ones, it appears you've shown OpenWrt default behavior is to preferentially load the big cores - as intended by the linked commit. However, irqbalance appears to spread the load in core order (first to last) across the little cores first without regard for big versus little cores.
If it has no logic (by default or added by you) to distinguish between big and little cores, "disabled" or not installed seems best.
Yeah I also tested packet steering too. Packet steering evenly loads all the cores but don’t know if it’s worth it if my network driver has Receive Side Scaling. Been testing out multiple things. However one thing I did notice that may or may not be related to my configuration. When I test bufferbloat on waveform with SQM disabled. My upload and download active latency reaches in the 100ms range. Quite odd. If I test connected straight to the bgw gateway. It isn’t that bad but right when I set up ip pass through and connect my nano. Bufferbloat is crazy high.
I use a NanoPi R5C gateway and recently switched to pppoe FTTH service from DOCSIS. I knew there would be a pppoe penalty, but it was bit steeper than I expected, so of course I started turning knobs.
My case is a bit different than yours - I'm basically running on the equivalent of your little cores only. FWIW though, I found global packet steering hurt throughput, so I disabled it. Irqbalance was no help either, so I stopped using it.
SQM is also off now. I'm a little disappointed SQM is too much for the CPU with the pppoe hit. But it is hard to care when latency on fiber without SQM is well below what I could achieve with SQM on a DOCSIS cable ISP anyway.