The v1 has no NEON support, which WireGuard has support for. I’m guessing it’s falling back to the C implementations for the crypto.
In any case, getting NEON on any Cortex A9 device in OpenWrt currently requires you to compile your own builds. Note that every device except the WRT1900ACv1 supports NEON.
Also note that as far as I know, there hasn’t been much work on getting WireGuard very well integrated with the kernel’s networking subsystem to take advantage of stuff like GRO and GSO.
Speed will improve over time. I don’t know if it’s possible to take advantage of VFP to speed up anything. Maybe poly1305 since it uses floating point.
In addition to the above, if you have a neon capable cpu you need to manually change the profile also setting -O2 instead of -Os might help performance a bit.
Thanks for the replies. The WRT1900ac is a v1 (mamba series). My reason for the testing is that I will be upgrading from my Internet from 180/20 to Gigabit in the next few months. At the end of the day I'm trying to determine if I can get away with purchasing a newer SOC based OpenWRT compatible router that can handle near Gigabit speed with Wireguard or look at a low powered X86 solution. I know the latter is almost mandatory for better OpenVPN performance.
You still need to recompile the rest of packages if you want to enable neon as the default CPU flags disables usage of NEON instructions. Do note that everything doesn't use NEON however.
Going to depend on what you include in your build, what the make file currently supports (i.e. does it support NEON OOTB, or do you need to un-comment a line). Mostly AV type transcode packages, just requires some investigation.
Mainly crypto and multimedia related software is what uses NEON instructions, there's support for most software that can use NEON in the tree and package repo. We could benefit greatly as far as zlib goes if someone could repackage the Chromimum fork of zlib as upstream seems quite dead.
Most software wont tell, libx264 (via ffmpeg) for instance will however.