I'm afraid I can not test it. Because iOS and Android ipsec implementation doesn't support ctr method. And I'm using aes256-sha2 now.
Another question, can I expect that qce crypto driver would improve ipsec throughput significantly？ If not, we only need to disable CRYPTO_HW in kernel config to fix this issue. By the way, after disabling CRYPTO_HW, ipsec could reach 50Mbps, significantly less than wireguard's 260Mbps.
The latest test passes. 
Good work! I can paste the full results if helpful?
However ipsec is still not working. The errors are gone, but packets shown as flowing out but not back in. Doing some testing to make sure I haven't made a mistake copying over the config.
Thanks for testing this. If the tests passed, it is enough by itself for that part of the puzzle, but it apparently isn't enough to make VPN work. Right now I've opened a PR https://github.com/openwrt/openwrt/pull/2518.
I should have done that much earlier, as it should broaden our audience. We can still discuss it here, if you wish, but I think over there it would be more productive.
Anyway, I've added an option to build the engine with only SK ciphers, hashes or both. AES is not the only algorithm being offloaded to the QCE--SHA1 & SHA256 are as well. The next part is to figure out if both your problem with AES-CTR, and @cwbsw's with AES-CBC can be eliminated by disabling hashes or ciphers.
Notice that the PR has all of the patches I posted here.
Perfect, and thank you for all your help so far. It's been hugely valuable and informative.
How do I disable CRYPTO_HW? I'm keen to check that ipsec works with that, to eliminate other problems. I assume it's in menuconfig, but I can't see an obvious setting.
It’s hardcoded in target/linux/ipq40xx/config-4.19 (I’m using my phone, so adjust the path as needed). Comment the line with CONFIG_CRYPTO_DEV_QCE=y, which is the actual driver being used.
Thanks. The identical ipsec configuration works when CONFIG_CRYPTO_DEV_QCE=n so whatever problem there is is definitely in QCE.
Yes, the problem is with QCE. There are two main components provided by QCE: AES-(CBC|CTR) and SHA(1|256). Try to turn off one at a time to see which one fails (or both 
). This needs the latest patch I've posted in the github PR#. You may only need the last commit, since you've probably already applied the other one. There should be a new option under Global build settings, Kernel build options: Algorithms enabled for QCE acceleration. It should be the first option without brackets, after the list of Compile the kernel with... options. If you select Block Ciphers Only, QCE will provide AES, but not SHA; Hash/HMAC only will do the opposite.
@cotequeiroz @leoc
I applied the pull request and tried these two options with aes256-sha256 cipher.
Block Ciphers Only : about 5Mbps downlink (router as encrypter), about 10Mbps uplink.
Hash/HMAC : about 5Mbps both downlink and uplink.
Using the same test you've just measured now, what's the speed (a) without hw-crypto/qce, and (b) with qce-all algorithms?
Compared with the numbers that were mentioned in the other thread, yours appear still far from the 40Mbps with original FW, but much better than the 1Mbps originally reported with the original qce driver.
I'll take a look at what the AES driver is doing, compared to other crypto engines, to try to catch something wrong/missing. My goal is to try to fix AES first, since it demands more horsepower from the CPU.
Option qce-all is similar to none additional patch applied, under 1Mbps downlink with many retr count in iperf3's output, and under 5Mbps uplink.
I got 30Mbps downlink and 40Mbps uplink without hw-crypto/qce. Also, I run iperf3 server on the router itself, maybe this can explain the difference between downlink and uplink. The iperf3 process eat more cpu resource when sending packets.
I've just updated the PR to remove the QCE driver from the kernel image, and have it built as a module instead.
I've added @cwbsw's speed measurements to the build-option help.
@leoc, can you test AES-CTR with ipsec, when building QCE with ciphers only, to see if it works, even if performance is poor?
Then I'll submit the patches upstream, and mark the PR as ready to review.
Kernel module compiling failed.
mkdir -p /home/build/openwrt/staging_dir/target-arm_cortex-a7+neon-vfpv4_musl_eabi/root-ipq40xx/stamp
SHELL= flock /home/build/openwrt/tmp/.root-copy.flock -c 'cp -fpR /home/build/openwrt/build_dir/target-arm_cortex-a7+neon-vfpv4_musl_eabi/linux-ipq40xx_generic/packages/.pkgdir/kernel/. /home/build/openwrt/staging_dir/target-arm_cortex-a7+neon-vfpv4_musl_eabi/root-ipq40xx/'
touch /home/build/openwrt/staging_dir/target-arm_cortex-a7+neon-vfpv4_musl_eabi/root-ipq40xx/stamp/.kernel_installed
ERROR: module '/home/build/openwrt/build_dir/target-arm_cortex-a7+neon-vfpv4_musl_eabi/linux-ipq40xx_generic/linux-4.19.80/drivers/crypto/qcrypto.ko' is missing.
modules/crypto.mk:410: recipe for target '/home/build/openwrt/bin/targets/ipq40xx/generic/packages/kmod-crypto-hw-qce_4.19.80-1_arm_cortex-a7_neon-vfpv4.ipk' failed
make[3]: *** [/home/build/openwrt/bin/targets/ipq40xx/generic/packages/kmod-crypto-hw-qce_4.19.80-1_arm_cortex-a7_neon-vfpv4.ipk] Error 1
make[3]: Leaving directory '/home/build/openwrt/package/kernel/linux'
time: package/kernel/linux/compile#3.14#0.29#3.56
package/Makefile:111: recipe for target 'package/kernel/linux/compile' failed
make[2]: *** [package/kernel/linux/compile] Error 2
make[2]: Leaving directory '/home/build/openwrt'
package/Makefile:107: recipe for target '/home/build/openwrt/staging_dir/target-arm_cortex-a7+neon-vfpv4_musl_eabi/stamp/.package_compile' failed
make[1]: *** [/home/build/openwrt/staging_dir/target-arm_cortex-a7+neon-vfpv4_musl_eabi/stamp/.package_compile] Error 2
make[1]: Leaving directory '/home/build/openwrt'
/home/build/openwrt/include/toplevel.mk:225: recipe for target 'world' failed
make: *** [world] Error 2
Sorry, I've messed up the module's path; it should have copied it from /home/build/openwrt/build_dir/target-arm_cortex-a7+neon-vfpv4_musl_eabi/linux-ipq40xx_generic/linux-4.19.80/drivers/qce/crypto/qcrypto.ko I've pushed a commit fixing this. Try again after reapplying the patch--there should be no need to clean your build. A make package/linux/compile should build it.
Edited to mention the PR push fixing this