Re: [PATCH v2 0/4] crypto: rockchip: Add RK356x/RK3588 cryptographic offloader
From: Eric Biggers <ebiggers@kernel.org>
Date: 2026-08-18 20:38:10
Also in:
linux-crypto, linux-devicetree, linux-rockchip, lkml
On Tue, Aug 18, 2026 at 10:23:18PM +0200, Diederik de Haas wrote:
On Tue Aug 18, 2026 at 10:04 PM CEST, Eric Biggers wrote:quoted
tcrypt.c reports cycle counts from get_cycles(), which has an architecture-dependent meaning. On x86_64 it is something approximating the CPU cycles (3-5 GHz) whereas on arm64 it is the ARM Generic Timer which tends to be around 24 MHz or so, over 100 times slower than the actual CPU. So 9044 vs 115 "cycles" for x86_64 vs arm64 sounds about expected, and they suggest the real times are likely similar but slightly faster on x86_64 as expected.Phew, thanks for the explanation :-)quoted
This sort of thing is why benchmarks usually should measure real time. The legacy module tcrypt.c unfortunately uses get_cycles() instead.What would be a better/non-legacy way to test crypto performance? Is that documented somewhere?
The KUnit tests in lib/crypto/tests/ have benchmarks in them. They can be run like any other KUnit tests, though you do need to set CONFIG_CRYPTO_LIB_BENCHMARK=y to enable the benchmark test cases. I'll add some more information to libcrypto.rst about how to do this, but besides the extra option it's no different from any other KUnit tests. Anyway, that is just for the code that actually matters, not legacy drivers like this one. So you're right to have used tcrypt.c to try to benchmark this legacy driver, as it is one of the ways to do so, just it is a bit pointless since this type of driver is known to be very slow. - Eric