Okay…
How about you use a client device to connect to the iperf3 server hosted on the Bpi?
As far as i know now the offloading works not stable…counters need to change when running the kcapi command…your broken network is caused by the crypto-stack you put on top which tries to use the broken offloading driver. Just try without the offloading code for now.
I see.
Trying to get into the business of Linux kernel maintenance myself. Could I help in anyway to fix that offloading driver? I would need some pointers.
I also do not much about it…i took code applied it and asked author for ways to test
You could discuss here too,make tests,maybe help him debugging.
I have much more things to do and not needing the crypto offload on r2pro.
Corentin posted new version of the patches
https://patchwork.kernel.org/project/linux-rockchip/list/?series=799470
Have added it here,but only compile-tested: Commits · frank-w/BPI-Router-Linux · GitHub
update of the test above with the new version and figuring out which options i need too
root@bpi-r2pro:~# cat /sys/kernel/debug/rk2_crypto/stats
rk2-crypto fe380000.crypto requests: 581
ecb-aes-rk2 ecb(aes) reqs=132 fallback=1994
fallback due to length: 342
fallback due to alignment: 1648
fallback due to SGs: 0
cbc-aes-rk2 cbc(aes) reqs=156 fallback=2182
fallback due to length: 329
fallback due to alignment: 1841
fallback due to SGs: 6
xts-aes-rk2 xts(aes) reqs=137 fallback=2143
fallback due to length: 116
fallback due to alignment: 739
fallback due to SGs: 0
rk2-md5 md5 reqs=14 fallback=739
rk2-sha1 sha1 reqs=28 fallback=716
rk2-sha256 sha256 reqs=25 fallback=654
rk2-sha384 sha384 reqs=32 fallback=656
rk2-sha512 sha512 reqs=34 fallback=638
rk2-sm3 sm3 reqs=23 fallback=712
root@bpi-r2pro:~# kcapi-rng -b 512 > rng.bin
root@bpi-r2pro:~# cat /sys/kernel/debug/rk2_crypto/stats
rk2-crypto fe380000.crypto requests: 581
ecb-aes-rk2 ecb(aes) reqs=132 fallback=1994
fallback due to length: 342
fallback due to alignment: 1648
fallback due to SGs: 0
cbc-aes-rk2 cbc(aes) reqs=156 fallback=2182
fallback due to length: 329
fallback due to alignment: 1841
fallback due to SGs: 6
xts-aes-rk2 xts(aes) reqs=137 fallback=2143
fallback due to length: 116
fallback due to alignment: 739
fallback due to SGs: 0
rk2-md5 md5 reqs=14 fallback=739
rk2-sha1 sha1 reqs=28 fallback=716
rk2-sha256 sha256 reqs=25 fallback=654
rk2-sha384 sha384 reqs=32 fallback=656
rk2-sha512 sha512 reqs=34 fallback=638
rk2-sm3 sm3 reqs=23 fallback=712
root@bpi-r2pro:~#
But at least no trace anymore. Answered in ML about the static values from test and the requirement of the older crypto driver
Thank you Frank, it is Thanksgiving so I had some time to test.
The IRC chat on #linux-rockchip concluded that I did not need hardware acceleration to achieve near gigabit speed on ipsec. The #linux roasted the gmac driver on rk3568 that it is stifling 1 CPU with soft interrupts.
I used an AX210 over the onboard gmac and it turns out the WAN link with the AX210 and iwlwifi driver gives a better performance (211Mbps → 255Mbps) than gmac0 (eth0).
The next question would be why would gmac processing and soft irqs from the gmac be hogging only CPU 0?
I got response on Mailinglist that my test does not work because rng is not supported yet. On mtk boards you can change affinity for the network interrupts,but idk if this can be done for rockchip too…
I actually done the manual move, see another thread, but there seems to be 2 queues per gmac but only one is used for some reason. Is that a driver issue or a device tree issue?