OpenSSL + opencrypto

[Jason Thorpe <thorpej%wasabisystems.com@localhost>]

I applied Jonathan's patch to OpenSSL to enable use of opencrypto.  
Here are the results of the following commands:

        openssl speed -evp des-ede3-cbc

libcrypto (/dev/crypto no present)
---------
Doing des-ede3-cbc for 3s on 16 size blocks: 201124 des-ede3-cbc's in 
3.00s
Doing des-ede3-cbc for 3s on 64 size blocks: 51381 des-ede3-cbc's in 
3.01s
Doing des-ede3-cbc for 3s on 256 size blocks: 12912 des-ede3-cbc's in 
3.01s
Doing des-ede3-cbc for 3s on 1024 size blocks: 3233 des-ede3-cbc's in 
3.01s
Doing des-ede3-cbc for 3s on 8192 size blocks: 404 des-ede3-cbc's in 
3.02s

cryptodev software (/dev/crypto present, no hifn driver in kernel)
------------------
Doing des-ede3-cbc for 3s on 16 size blocks: 61531 des-ede3-cbc's in 
0.20s
Doing des-ede3-cbc for 3s on 64 size blocks: 46481 des-ede3-cbc's in 
0.08s
Doing des-ede3-cbc for 3s on 256 size blocks: 22956 des-ede3-cbc's in 
0.04s
Doing des-ede3-cbc for 3s on 1024 size blocks: 7496 des-ede3-cbc's in 
0.01s
Doing des-ede3-cbc for 3s on 8192 size blocks: 1041 des-ede3-cbc's in 
0.00s

cryptodev hifn (/dev/crypto present, hifn driver in kernel)
--------------
Doing des-ede3-cbc for 3s on 16 size blocks: 36353 des-ede3-cbc's in 
0.15s
Doing des-ede3-cbc for 3s on 64 size blocks: 34432 des-ede3-cbc's in 
0.12s
Doing des-ede3-cbc for 3s on 256 size blocks: 28077 des-ede3-cbc's in 
0.05s
Doing des-ede3-cbc for 3s on 1024 size blocks: 15986 des-ede3-cbc's in 
0.07s
Doing des-ede3-cbc for 3s on 8192 size blocks: 3245 des-ede3-cbc's in 
0.00s

Obviously for smaller transforms, using the libcrypto version is 
better; this is fairly obvious, since the ioctls have overhead.

It's interesting to note that the cryptosoft implementation for 
256-byte blocks is faster than the libcrypto implementation.  I am not 
sure why.

The hifn is slower than everything until 256-byte (again, ioctl 
overhead + hardware setup overhead), but then it is faster.  This is a 
32-bit card in a 33MHz slot.  It's not a new card by any stretch of the 
imagination.  It's also behind 3 PCI-PCI bridges (don't ask).

And, finally, the hifn driver seems to be buggy.  When I use cryptodev 
+ hifn, I get "data modified on freelist" and "panic: amap_wipeout: 
corrupt map".  I'll see if I can try and track that down.  No promises, 
though :-)

Anyway, from this info, it would be nice to put some intelligence in 
libcrypto so it could decide when to use an engine and when to use the 
base libcrypto software implementation of the transform.

        -- Jason R. Thorpe <thorpej%wasabisystems.com@localhost>