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

[Eric Biggers]

On Tue, Aug 18, 2026 at 09:31:17PM +0200, Diederik de Haas wrote:
> On Tue Aug 18, 2026 at 8:58 PM CEST, Eric Biggers wrote:
> > On Mon, Aug 03, 2026 at 12:42:03PM +0200, Diederik de Haas wrote:
> >> crypto-rk3566-test-no-crypto-module-log.txt:
> >> https://paste.sr.ht/~diederik/bb5dbfd59f244a6422b965b30f9796ebbfdb1fcb
> >> crypto-rk3566-test-with-crypto-module-log.txt:
> >> https://paste.sr.ht/~diederik/ea72297678e19cbbc987de9548f9884382e1d1cc
> >> crypto-rk3568-test-no-crypto-module-log.txt:
> >> https://paste.sr.ht/~diederik/309e519e6b1c31f4c1c5bcb1ea16cc8569a54830
> >> crypto-rk3568-test-with-crypto-module-log.txt:
> >> https://paste.sr.ht/~diederik/1e1e938ebbbae75128974fe0a7c240843bce04c8
> >> crypto-rk3588-test-no-crypto-module-log.txt:
> >> https://paste.sr.ht/~diederik/9a2adc2b2e42131445ce4576589e00ecf51ccb4b
> >> crypto-rk3588-test-with-crypto-module-log.txt:
> >> https://paste.sr.ht/~diederik/e04c11c8809031ca45662f7d4c227c1ba6162b65
> >
> > Thanks for running some benchmarks!
> >
> > Looking at your results for rk3566 for example, SHA-256 on 4096-byte
> > blocks is 115 cycles/operation for sha256-lib (i.e. ARMv8 CE) or 3027
> > cycles/operation for rk2-sha256.  So the Rockchip driver is 26 times
> > slower than simply using the existing well-tested CPU-based code.
> 
> I shared the results because:
> 1) I figured it might be useful to have these numbers
> 2) I didn't know how to interpret the results.
> 
> Because a lower cycles/operations would IMO *logically* be better and
> your response above seems to confirm that.
> 
> Which makes the following results a 'bit' concerning?
> ``modprobe tcrypt mode=404``
> 
> [255753.686837] tcrypt: testing speed of async sha256 (sha256-lib)
> [255753.686841] tcrypt: test  0 (   16 byte blocks,   16 bytes per update,   1 updates):    703 cycles/operation,   43 cycles/byte
> [255753.686848] tcrypt: test  1 (   64 byte blocks,   16 bytes per update,   4 updates):   1101 cycles/operation,   17 cycles/byte
> [255753.686856] tcrypt: test  2 (   64 byte blocks,   64 bytes per update,   1 updates):    869 cycles/operation,   13 cycles/byte
> [255753.686861] tcrypt: test  3 (  256 byte blocks,   16 bytes per update,  16 updates):   1676 cycles/operation,    6 cycles/byte
> [255753.686871] tcrypt: test  4 (  256 byte blocks,   64 bytes per update,   4 updates):   1059 cycles/operation,    4 cycles/byte
> [255753.686877] tcrypt: test  5 (  256 byte blocks,  256 bytes per update,   1 updates):   1249 cycles/operation,    4 cycles/byte
> [255753.686884] tcrypt: test  6 ( 1024 byte blocks,   16 bytes per update,  64 updates):   4156 cycles/operation,    4 cycles/byte
> [255753.686904] tcrypt: test  7 ( 1024 byte blocks,  256 bytes per update,   4 updates):   1054 cycles/operation,    1 cycles/byte
> [255753.686911] tcrypt: test  8 ( 1024 byte blocks, 1024 bytes per update,   1 updates):   2826 cycles/operation,    2 cycles/byte
> [255753.686923] tcrypt: test  9 ( 2048 byte blocks,   16 bytes per update, 128 updates):   7438 cycles/operation,    3 cycles/byte
> [255753.686957] tcrypt: test 10 ( 2048 byte blocks,  256 bytes per update,   8 updates):   1263 cycles/operation,    0 cycles/byte
> [255753.686966] tcrypt: test 11 ( 2048 byte blocks, 1024 bytes per update,   2 updates):    940 cycles/operation,    0 cycles/byte
> [255753.686973] tcrypt: test 12 ( 2048 byte blocks, 2048 bytes per update,   1 updates):   4887 cycles/operation,    2 cycles/byte
> [255753.686991] tcrypt: test 13 ( 4096 byte blocks,   16 bytes per update, 256 updates):  14017 cycles/operation,    3 cycles/byte
> [255753.687054] tcrypt: test 14 ( 4096 byte blocks,  256 bytes per update,  16 updates):   1681 cycles/operation,    0 cycles/byte
> [255753.687065] tcrypt: test 15 ( 4096 byte blocks, 1024 bytes per update,   4 updates):   1059 cycles/operation,    0 cycles/byte
> [255753.687074] tcrypt: test 16 ( 4096 byte blocks, 4096 bytes per update,   1 updates):   9044 cycles/operation,    2 cycles/byte
> [255753.687105] tcrypt: test 17 ( 8192 byte blocks,   16 bytes per update, 512 updates):  27155 cycles/operation,    3 cycles/byte
> [255753.687224] tcrypt: test 18 ( 8192 byte blocks,  256 bytes per update,  32 updates):   2489 cycles/operation,    0 cycles/byte
> [255753.687241] tcrypt: test 19 ( 8192 byte blocks, 1024 bytes per update,   8 updates):   1268 cycles/operation,    0 cycles/byte
> [255753.687253] tcrypt: test 20 ( 8192 byte blocks, 4096 bytes per update,   2 updates):    959 cycles/operation,    0 cycles/byte
> [255753.687263] tcrypt: test 21 ( 8192 byte blocks, 8192 bytes per update,   1 updates):  17812 cycles/operation,    2 cycles/byte
> 
> This is on my AMD Ryzen 7 5800X which I would've expected to blow
> a simple RK3566 SBC out of the water ... :-/

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.

This sort of thing is why benchmarks usually should measure real time.
The legacy module tcrypt.c unfortunately uses get_cycles() instead.

> > Don't you love "accelerators" that make things 26 times slower?
> >
> > I guess we'll get the usual argument that this driver is really just for
> > "testing" or whatever.
> 
> Or someone spend a significant time implementing it trying to improve and
> extend SoC support in good faith, but without your insight. 
> Which is 'coincidentally' the exact reason why I suggested the patch series
> author to explicitly put you in To or CC.
> I would not have used "pushing the driver as a checkbox feature" as argument.
> Especially since, apparently, the numbers show it performs poorly.

Well, hopefully that's the case and people actually care about reality
for this one.  The other drivers in drivers/crypto/ have the same
problem but they are pushed anyway, so the track record isn't great.

- Eric