kevery has quit [Remote host closed the connection]
<linkmauve>
montjoie, I just did some benchmarks of hashes (not checking for correctness), just benchmarking AF_ALG it starts getting faster than plain CPU at around 16 KiB, with 8 KiB input it’s slower; and your driver makes it about three orders of magnitude slower, so something weird might be going on.
<linkmauve>
Except for 64 KiB input, where it is now faster than a pure CPU implementation again, which makes me think your driver gets skipped for this input size and the NEON kernel implementation gets picked instead.
vagrantc has joined #linux-rockchip
<linkmauve>
To get an idea of the timings, for the SHA-1 of a 4096 B buffer, it takes 17.49 µs in pure CPU (using the sha1 crate), 39.08 µs using AF_ALG with the sha256-arm64-neon driver, and 11.51 ms (note the unit) using rk2-sha256.
<linkmauve>
And 6.889 µs when enabling the asm feature in the sha1 crate.
<linkmauve>
At which point it expectedly beats all variants of software AF_ALG.
Stat_headcrabed has quit [Quit: Stat_headcrabed]
Stat_headcrabed has joined #linux-rockchip
Stat_headcrabed has quit [Client Quit]
Stat_headcrabed has joined #linux-rockchip
Stat_headcrabed has quit [Client Quit]
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
psydroid has joined #linux-rockchip
psydroid has quit [Client Quit]
warpme has joined #linux-rockchip
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
warpme has joined #linux-rockchip
warpme has quit [Client Quit]
psydroid has joined #linux-rockchip
warpme has joined #linux-rockchip
<montjoie>
AF_ALG is always slow, I dont think crypto IP is a good idea for user space
<linkmauve>
It’s the only way to use the hardware blocks isn’t it?
<montjoie>
you could try cryptodev which faster but offtree
<linkmauve>
Besides that out of tree module with a different uABI.
<montjoie>
for the 64kb size, you cou can check if driver is bypasser by checking its debug stats
crabbedhaloablut has quit []
sukrutb has joined #linux-rockchip
warpme has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<macromorgan__>
so here's a weird case... for a device I'm working on (Powkiddy X55, RK3566) I have to mark the aclk_usb as a critical clock, or else the 2nd SD card (sdmmc2) fails to work. Why would that be? I don't see how aclk_usb is related in any way...
<CounterPillow>
could this be one of those linked clock things where one clock has multiple parents and mainline doesn't model it well yet?
<macromorgan__>
I'm almost certain now that I read it
<macromorgan__>
it looks like aclk_usb is the parent of pclk_usb. There's a note that "pclk_usb_niu" has a dependency on "hclk_usb_niu". If the relationship goes both ways that would make sense.
<macromorgan__>
since hclk_usb is already listed as a critical clock, I'm wondering if I should also list aclk_usb (or more technically pclk_usb)?