Hello, Thank you for the quick reply.
I use the mv_cesa driver as shipped by Debian with the 3.16 kernel, which is almost certainly the same as mainline. I tried to run the _comp tools with mv_cesa removed: fijam@yukikaze:~/cryptodev-linux-1.7/tests$ ./cipher_comp && ./hash_comp requested cipher CRYPTO_AES_CBC and mac CRYPTO_SHA1_HMAC, got cipher cbc(aes) with driver cbc(aes-generic) and hash with driver requested mac CRYPTO_SHA1, got hash sha1 with driver sha1-asm and loaded: fijam@yukikaze:~/cryptodev-linux-1.7/tests$ sudo modprobe mv_cesa fijam@yukikaze:~/cryptodev-linux-1.7/tests$ ./cipher_comp && ./hash_comp requested cipher CRYPTO_AES_CBC and mac CRYPTO_SHA1_HMAC, got cipher cbc(aes) with driver mv-cbc-aes and hash with driver requested mac CRYPTO_SHA1, got hash sha1 with driver sha1-asm They both pass, but note that even with mv_cesa loaded, sha1-asm is used. I checked /proc/crypto and mv_cesa has indeed the highest priority (300). I tried to rmmod sha1_generic and sha1_arm but they just get loaded again. I am not very familiar with kernel self-checks. I tested with the tcrypt module (mode 200 for aes and mode 303 for sha) and I think I'm on the right track: [227229.582143] alg: hash: Test 3 failed for mv-sha1 [227229.586891] 00000000: 10 bf d7 00 71 0b bb 83 3a 26 d0 97 13 05 99 f5 [227229.593454] 00000010: 3a 92 53 3c [227229.597165] alg: hash: Test 1 failed for mv-hmac-sha1 [227229.602343] 00000000: 0c aa 9f d5 37 c3 79 3a 91 d9 21 5f 42 2b 2c 24 [227229.608906] 00000010: b7 c3 16 0c [227251.303414] [227251.303414] testing speed of sha1 [227251.323114] test 0 ( 16 byte blocks, 16 bytes per update, 1 updates): 518331 opers/sec, 8293296 bytes/sec [and so on] It would appear that mv_sha1 fails, at which point the generic driver gets loaded? Does it mean the kernel driver itself is at fault? Cheers, Jan On Mon, Apr 27, 2015 at 1:08 PM, Phil Sutter <p...@nwl.cc> wrote: > Hello Jan, > > On Mon, Apr 27, 2015 at 12:44:50PM +0200, JM wrote: > > I installed cryptodev 1.7 on my Debian box running on Marvell Feroceon > > processor (featuring mv_cesa hardware accelerator). I'm running debian > > wheezy with openssl_1.0.1e (with enabled cryptodev and the two > recommended > > patches) and kernel 3.16 from backports. > > > > My problem is that SHA1 acceleration doesn't seem to work, while it > should > > be supported by the engine. > > Specifically the combination of cryptodev and CESA (although with > heavily modified driver) is what we use at work and does a decent job. > > > If I run ./sha_speed in tests I always get the sha1-asm fallback driver, > > instead of mv-sha1. > > This per se does not sound like a cryptodev problem. A few things I > would like you to check: > > - Run the *_comp tools to see if cryptodev returns correct output > - same as above with mv_cesa.ko unloaded (i.e., forcing software > implementations in kernel). > - Are the kernel crypto self-tests enabled? Maybe the one for mv-sha1 > fails? > - Enable kernel crypto self-tests if not already happening and check if > they succeed. > - What's the priority of each sha1 provider in /proc/crypto? Although it > shouldn't, maybe mv-sha1 is considered slower than sha1-asm? > - Since at the moment an alternative driver is out for review, are you > using the mainline mv_cesa.c or something else? > > Cheers, Phil > > _______________________________________________ > Cryptodev-linux-devel mailing list > Cryptodev-linux-devel@gna.org > https://mail.gna.org/listinfo/cryptodev-linux-devel >
_______________________________________________ Cryptodev-linux-devel mailing list Cryptodev-linux-devel@gna.org https://mail.gna.org/listinfo/cryptodev-linux-devel
