On Mon, Sep 24, 2012 at 08:08:59PM +0200, Nikos Mavrogiannopoulos wrote: > On 09/23/2012 11:54 PM, Lluís Batlle i Rossell wrote: > > >> Specifically, this 3.5.4 reports on dmesg: > >> MV-CESA:Fallback driver 'hmac(sha1)' could not be loaded! > >> MV-CESA:Fallback driver 'sha1' could not be loaded! > >> > >> This happens every time I run something doing sha1 in openssl. Let it be > >> openssl > >> speed, or a new openssh connection. > >> > >> openssl speed -evp sha1 > >> reports a very slow speed. > >> > >> Simply, I noticed that openssh transfers took a lot of time, and I thought > >> it > >> was due to this sha1 problem. "perf top" points at openssh doing lots of > >> libcrypto:sha1, while cesa does the AES. > >> Any idea what happens? Why cesa is not accelerating the sha1? > > Oh I think I see it. The mv_cesa wants a fallback for sha1, like a software > > sha1. My kernel lacked CRYPTO_SHA1. > > > I'll try rebuilding the kernel with it. > > There will be no much change. If you mv_cesa doesn't support sha1, it > may be faster to use the userspace implementation of sha1.
I got it working. Simply, the mv_cesa wants a 'fallback'. Maybe for some shorter-than-usual-length blocks or so. No idea. 'openssl speed' shows a big improvement on sha1. Nevertheless, on openssh I don't see much improvement (aes128+sha1), although both are used through cryptodev. With 'perf top', I see that all the time is spent in memcpy, both at the kernel mv_crypto thread and the userspace sshd. No idea how to get a faster scp/sftp. Regards, Lluís. _______________________________________________ Cryptodev-linux-devel mailing list Cryptodev-linux-devel@gna.org https://mail.gna.org/listinfo/cryptodev-linux-devel
