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 "0001-cryptodev-Fix-issue-with-signature-generation.patch". (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!): http://events.linuxfoundation.org/sites/events/files/slides/Dma%20Optimization%20BayLibre%20Guillene%20v4.pdf They don't sound too thrilling compared to a FSL P1010 i've got around that gives ~1500 mbit/s with big packets. Regards. _______________________________________________ Cryptodev-linux-devel mailing list Cryptodev-linux-devel@gna.org https://mail.gna.org/listinfo/cryptodev-linux-devel
