Hi, On 6/25/25 08:32, Eric Biggers wrote:
That was the synchronous throughput. However, submitting multiple requests asynchronously (which again, fscrypt doesn't actually do) barely helps. Apparently the STM32 crypto engine has only one hardware queue. I already strongly suspected that these non-inline crypto engines aren't worth using. But I didn't realize they are quite this bad. Even with AES on a Cortex-A7 CPU that lacks AES instructions, the CPU is much faster!
From a performance perspective, using hardware crypto offloads the CPU, which is important in real-world applications where the CPU must handle multiple tasks. Our processors are often single-core and not the highest performing, so hardware acceleration is valuable.
I can show you performance test realized with openSSL (3.2.4) who shows, less CPU usage and better performance for large block of data when our driver is used (via afalg):
command used: ```openssl speed -evp aes-256-cbc -engine afalg -elapsed``` +--------------------+--------------+-----------------+ | Block Size (bytes) | AFALG (MB/s) | SW BASED (MB/s) | +--------------------+--------------+-----------------+ | 16 | 0.09 | 9.44 | | 64 | 0.34 | 11.43 | | 256 | 1.31 | 12.08 | | 1024 | 4.96 | 12.27 | | 8192 | 18.18 | 12.33 | | 16384 | 22.48 | 12.33 | +--------------------+--------------+-----------------+ to test CPU usage I've used a monocore stm32mp157f. here with afalg, we have an average CPU usage of ~75%, with the sw based approach CPU is used at ~100% Maxime
