JT --

On Fri, Jul 26, 2013 at 6:18 PM, JT Olds <he...@jtolds.com> wrote:

> I'm not totally sure the tests exercised cryptodev.ko,

I can't speak to the rest of your questions, but an easy way to test
that the cryptodev is being used is to use the openssl speed test.
The native / default mode is to report CPU seconds spent in the
openssl code, and extrapolate throughput based on that number  (Which,
if you can be doing other stuff on your main CPU while your crypto
coprocessor is humming along, that's still a win...)

E.g., on my ppc32 box:

type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes

with cryptodev, but without -evp:
sha1               209.57k      840.45k     3080.90k    12999.92k    87082.87k
aes-128 cbc       5545.37k     5926.98k     6100.18k     6108.30k     6016.78k

with cryptodev, with -evp:
sha1               205.13k      806.63k     3077.01k    11163.69k    96560.57k
aes-128-cbc       2180.50k     9859.66k    35055.54k   135002.58k   668525.71k

without cryptodev, without evp:
sha1               557.61k     2232.21k     7331.32k    17588.00k    28284.46k
aes-128 cbc       5537.78k     5924.95k     6012.02k     6088.89k     6015.80k

without cryptodev, with -evp:
sha1               492.30k     1936.51k     6548.92k    16087.43k    27540.13k
aes-128-cbc       5058.52k     5756.05k     6031.66k     6064.66k     6072.83k

This is on a 266MHz MPC8315E.  You're not really getting 670MB/s
throughput on AES there; rather, openssl only accounted for the
"visible" CPU cycles (mostly setting up buffers etc); the work the SEC
does is not visible.

Command lines here:

https://mail.gna.org/public/cryptodev-linux-devel/2013-04/msg00008.html

> but I do know for certain the
> existence of cryptodev.ko in the kernel definitely kills a ton of SSL
> handshakes with the appropriately built openssl library.

In my case, it turns out that "openssl speed" wasn't provoking the
errors, but my own application (signing and encrypting into CMS
format, not SSL) did provoke the error.  It seems that cryptodev on
this platform doesn't properly limit in-kernel crypto buffer sizes --
and the SEC on this chip can only accept 64Ki - 1 bytes at a time.

> Help?

Hope someone else has better news for you...

_______________________________________________
Cryptodev-linux-devel mailing list
Cryptodev-linux-devel@gna.org
https://mail.gna.org/listinfo/cryptodev-linux-devel

Reply via email to