Re: AES-NI: slower than aes-generic?

Am Donnerstag, 26. Mai 2016, 22:14:29 schrieb Theodore Ts'o:

Hi Theodore,

On Thu, May 26, 2016 at 08:49:39PM +0200, Stephan Mueller wrote:

quoted

Using the kernel crypto API one can relieve the CPU of the crypto work, if
a hardware or assembler implementation is available. This may be of
particular interest for smaller systems. So, for smaller systems (where
kernel bloat is bad, but where now these days more and more hardware
crypto support is added), we must weigh the kernel bloat (of 3 or 4
additional C files for the basic kernel crypto API logic) against
relieving the CPU of work.

There are a number of caveats with using hardware acceleration; one is
that many hardware accelerators are optimized for bulk data
encryption, and so key scheduling, or switching between key schedules,
can have a higher overhead that a pure software implementation.

As a followup: I tweaked the DRBG side a bit to use the full speed of the AES-
NI implementation. With that tweak, the initial finding does not apply any 
more.

I depending on the request size, I now get more than 800 MB/s (increase by 
more than 450% compared to the initial implementation) from the AES-NI 
implementation. Hence, the frequent key schedule update seems to be not too 
much of an issue.

Ciao
Stephan