[PATCH v2 0/4] crypto: rockchip: Add RK356x/RK3588 cryptographic offloader

[Eric Biggers]

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:
> > 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 :-)
> 
> > 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