Apologies if this is stated earlier in the thread, but you did build your OpenSSL with -DUSE_CRYPTODEV_DIGESTS, right?
What version of OpenSSL are you using? Have you perchance checked whether sshd works with cryptodev offload (ssh -c aes128-cbc to your cryptodev machine)? Gordan On 30/05/15 12:43, JM wrote:
Hello again, I have updated the kernel on the affected machine to 4.0.4 and now mv_cesa successfully passes self checks. I rebuilt the cryptodev-linux module with the compilation fix from git and the tests included in cryptodev also pass now. However, I am having trouble doing sha1 hashing using mv_cesa through cryptodev from other applications, while aes-128-cbc works correctly. Tested with openssl (built with the recommended patches and flags): AES: openssl speed aes-128-cbc -elapsed software path is taken openssl speed -evp aes-128-cbc -elapsed offloading works correctly, and I see mv_crypto taking CPU time SHA1: openssl speed sha1 -elapsed software path is taken openssl speed -evp sha1 -elapsed software path is taken, no difference in speed, mv_crypto at 0% CPU time this is what I get in dmesg with verbosity set to 3: -evp aes: http://pastebin.com/K3TaJ2S8 -evp sha1: http://pastebin.com/udK6EYwS In /proc/crypto I have name : sha1 driver : mv-sha1 module : mv_cesa priority : 300 refcnt : 1 selftest : passed type : ahash async : yes blocksize : 64 digestsize : 20 which is the highest priority for sha1 that I have in this system. Importantly, ./sha_speed from cryptodev-linux/tests correctly requests mv-sha1 and I can see it use mv_crypto in the process list with about 45% cpu usage. To summarize, openssl can use mv_cesa through cryptodev only for aes-128-cbc and not for sha1, even though tests included in cryptodev can use mv_cesa for both aes and sha1. Can someone shed any light on that? Best regards, Jan On Mon, Apr 27, 2015 at 2:24 PM, Phil Sutter <p...@nwl.cc <mailto:p...@nwl.cc>> wrote: Hi, On Mon, Apr 27, 2015 at 02:08:29PM +0200, JM wrote: > 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. This wouldn't work anyway since mv_cesa needs a software implementation to fall back to for odd cases. > 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? Yes, indeed. I'm surprised it still turns up in /proc/crypto, but if the kernel self-test for a given crypto-provider fails it won't be used anymore (for good reason, of course). The driver failing with tcrypt is clear evidence of a driver problem and unrelated to cryptodev. Have a look at the kernel log, I bet there is output from the failing self-test at boot-time. Cheers, Phil _______________________________________________ Cryptodev-linux-devel mailing list Cryptodev-linux-devel@gna.org <mailto: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
_______________________________________________ Cryptodev-linux-devel mailing list Cryptodev-linux-devel@gna.org https://mail.gna.org/listinfo/cryptodev-linux-devel
