Hi Tony,
On 05/04/22 15:04, Tony He wrote:
Hi JJK,
Yeah, I know this way, but there is still context switching in the
kernel space and user space. I have been looking for a way
to benchmark in the kernel space. I expect there is a kernel module like below:
insmod benchmark.ko AES-256-GCM
Hi JJK,
Yeah, I know this way, but there is still context switching in the
kernel space and user space. I have been looking for a way
to benchmark in the kernel space. I expect there is a kernel module like below:
insmod benchmark.ko AES-256-GCM
(After it's done, this module will exit
hi Tony,
On 02/04/22 11:40, Tony He wrote:
Hi Antonio,
I am porting ovpn-dco to embedded ARMv8 device with hardware crypto
engine. However the performance is not very good.
It's about 130-140Mbps. I expect more. The SDK already provides kernel
CryptoAPI(CFI) interface to access the crypto
Hey Tony,
On 03/04/2022 04:44, Tony He wrote:
Any advice is welcome. Thank you!
Debugging/profiling the fast path is never easy, but your method is
definitely a reasonable approach.
Glad you already found the bottleneck.
An alternative is using the perf kernel tool, which tells you the
Hi,
I used below ugly way to benchmark the performance roughly. In POC,
confirmed the hardware crypto engine is the bottleneck and not very
fast
for packet not over than 1500 bytes. Overhead is required for queuing
the data to crypto engine and sending data back to kernel.
Hi Antonio,
I am porting ovpn-dco to embedded ARMv8 device with hardware crypto
engine. However the performance is not very good.
It's about 130-140Mbps. I expect more. The SDK already provides kernel
CryptoAPI(CFI) interface to access the crypto engine.
I want to know if the crypto operation is
