On 01/10/2015 03:37 PM, Justas Mikalajunas wrote:

> I have tried to apply patches provided in that link, but with no success.
> The provided patches are somewhat old, they need to be updated, lines do not
> match. Anyway, I have applied patches from
> http://arago-project.org/git/?p=meta-arago.git;a=tree;f=meta-arago-distro/re
> cipes-connectivity/openssl/openssl;hb=HEAD which does exactly the same.
> Still same problem occurring only for SCP (OpenSSH) so far. 

Let's keep the list CCed, someone else might be interested.
One of the patches applies cleanly (signature), the other
"0002-cryptodev-allow-copying-EVP-contexts.patch" is intended for the
openssl 1.0.2 codebase so yes it needs a backport and it's not really
the one that fixes the ssh issue.
Note that "patch.txt" is just an old version of
(i maintain this for the

> Also another problem. I tried to use Iperf to test cryptodev module. See
> result provided below. 
> OPENVPN 2.3.2 both ends.
> Iperf tests (Server - Ubuntu virtual machine--14.04, client - beaglebone
> black with yocto linux 3.14 kernel)
> No cryptodev, software implementation
> auth none, cipher   none                 36.5Mbits/sec            
> auth tls,       cipher   none                 31.3Mbit/sec               
> auth tls,       cipher   aes-256-cbc    26.2Mbit/sec         
> Cryptodev enabled
> auth none, cipher none                 35Mbits/sec 
> auth tls,       cipher none                 6Mbit/sec 
> auth tls,       cipher aes-256-cbc    3.99Mbit/sec 
> Huge throughput drop appears when hardware is used. Any ideas why? What is
> more, in /proc/interrupts I can see that OMAP-AES and OMAP-SHAM (hardware
> accelerators' drivers) are being used by drastically increasing amount of
> interrupts during tests.  I have posted on texas intruments forum, I have
> not got any response for a month.  My guess would be that context switching
> between kernel and user spaces overwhelms the job hardware accelerators
> does, but maybe not to that extent. 

There's one thing people must realize with hardware accelerated crypto -
it might not be faster than doing it in software, in fact it may even be
quite slower.
In my limited experience only the SoC manufacturers with a strong
communications background have very good performing crypto hardware.
What you gain sometimes from it is freeing up cpu cycles, a very quick
benchmark would be:

(try with the cryptodev module loaded and without)
$ openssl speed -evp aes256 -elapsed

Also for the kicks (and giving totally bogus numbers in many cases) try:
$ openssl speed -evp aes256

With the last one it's measuring CPU time, so you'll see how much cpu
using the crypto uses. However as openssl does bad math (multiply
results by the cpu time difference with the 4 second run) it will in
fact give totally inflated numbers which aren't real.

Also for small payloads (packets) the setup overhead makes everything
slower - that's for crypto offload based on a separate unit (not ISA,
like AES-NI or Padlock, since ISA has basically 0 overhead).

For OMAP i've found these numbers (sorry PDF!):
They don't sound too thrilling compared to a FSL P1010 i've got around
that gives ~1500 mbit/s with big packets.


Cryptodev-linux-devel mailing list

Reply via email to