@bitthief Any chance of sharing the NSS stuff?
I finally have some time this weekend and would really love to sort out the clocks as well so that I can send the whole series upstream next week.
Well, fixed regulator is needed for anything NSS-DRV related as it does voltage scaling internally, but its implemented using a fixed regulator on almost all boards.
You forgot the \n in the end of each echoed string, maybe that makes some difference?
And kmod-wireguard is duplicated, although that's not the problem.
All the lines you added should have the new-line char, to look like the already existing lines:
Yeah, I have updated my reply after I saw that OpenWrt already packages the NEON version for ARM64.
Thanks for checking.
I am doing OpenSSL benchmarks to see what QCE options work best for it as QCE engine seems slower then the CPU most of the time and IPQ40xx for example only enables it for skciphers.
There are more changes needed, on top of that. I'll push everything in a bit.
If you have time, I'm pretty sure I found the root cause for the interrupt issues during nf_conntrack notifier registrations very early in the boot (triggered by ECM).
The problems appear to be triggered with the following default sysctls:
11-br-netfilter.conf
# Do not edit, changes to this file will be lost on upgrades
# /etc/sysctl.conf can be used to customize sysctl settings
# disable bridge firewalling by default
net.bridge.bridge-nf-call-arptables=0
net.bridge.bridge-nf-call-ip6tables=0
net.bridge.bridge-nf-call-iptables=0
Even if you enable or disable bridging in ECM, literally anything that touches the nf_ct_bridge_register/unregister functions via those sysctls during early boot, will cause the issues I was seeing (kernel oops in interrupt handler). I know you did those patches, and I saw you added BLOCKING notifiers and ATOMIC notifiers etc. My guess is that something needs to be reworked there, I've added mutexes as a precaution in ECM, but it's not enough. It'd be great if you had a look and we also 'fix' this in the clean way.
And yes, that voltage regulator was missing in my config also, I'll add it:
That's easy to setup, I use 3 WireGuard tunnels all the time, from Njalla and Mullvad. I can give you a key/pair for Mullvad and the relevant config bits if you want to test easily. Otherwise, I can spin up a wireguard server on a test VPS etc. and give you keys to benchmark in like 20m.
It pulls in those modules from the kernel, but I'm not sure if they're SIMD optimized, my dream was to offload them to NSS also, in a bright future when we finished everything else. But to be honest, not sure it's worth the effort, at least for now, I can reach 400-450mbps (maximum that Mullvad offers) with maybe 1-2 cores pinned to around 60-70-% at peak.
IPQ4019 and IPQ8074 use the same QCE IP revision so they share the same restrictions.
Just a quick test:
QCE via devcrypto:
The 'numbers' are in 1000s of bytes per second processed.
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes
aes-256-cbc 15491.20k 82219.73k 173709.96k 752082.49k 8762709.33k 8279244.80k
Software implementation:
The 'numbers' are in 1000s of bytes per second processed.
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes
aes-256-cbc 10490.93k 49450.24k 552000.00k 985088.00k 26389708.80k 16639590.40k
Thanks for the offer, but since the optimized modules are already used there is no point.
They are ARM64 optimized modules that use NEON instructions so they are SIMD, since they are already hand-tuned NEON ASM there is not much you can do there.
FWIW, just building @bitthief's latest works fine on my AX6. Performance seems similar, but my entire uplink goes through Wireguard for reasons, so the hardware accelerated path is not taken often.
I can't take much credit for patches 600-604, the original versions are in IPQ807x-5.10-backports and I've just updated those for k5.15. 605 is mine though.
I've built your repo and included ecm, but my config is just an AP so it didn't get loaded. I added ecm to /etc/modules.d and it loaded on next boot without any errors, but I suspect that's down to no routing happening? I'll reconfigure it as a router and see if I can get it misbehaving...