Re: [PATCH] x86, crypto: ported aes-ni implementation to x86

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


On 30.10.2010, 00:15 Herbert Xu wrote:
> Mathias Krause <minipli@xxxxxxxxxxxxxx> wrote:
>> To illustrate the performance gain here's a short summary of the tcrypt
>> speed test on a Core i5 M 520 running at 2.40GHz comparing both
>> assembler implementations:
>> 
>>                            aes-i586   aes-ni-i586   delta
>> 256 bit, 8kB blocks, ECB:  46.81 MB/s   164.46 MB/s   +251%
>> 256 bit, 8kB blocks, CBC:  43.89 MB/s    62.18 MB/s    +41%
>> 384 bit, 8kB blocks, LRW:  42.24 MB/s   142.90 MB/s   +238%
>> 512 bit, 8kB blocks, XTS:  43.41 MB/s   148.67 MB/s   +242%
>> 
>> Signed-off-by: Mathias Krause <minipli@xxxxxxxxxxxxxx>
> 
> Oh and those CBC numbers look out of whack.  I'd expect CBC to be
> way faster as it's done directly by the hardware unlike the
> other modes.  What numbers do you get in 64-bit before/after
> your patch?
> 
> If the hardware CBC is really so much slower then maybe we should
> stop using it.

Today I build and measured a 64-bit version without my changes and got 
results for the above tests at around 60 to 66 MB/s which is ridiculous! 
So I ran the test again and again and noticed that _sometimes_ I got 
results for _some_ algorithms at 150 to 160 MB/s. That's weird!

Testing the 32-bit version again (with my patch) I even got 151 MB/s for 
the CBC mode, albeit now other algorithms were down to 58 - 67 MB/s. 
Strange. Looks like I was just lucky with my first measurement. :/

I don't know why the numbers do vary that much. Maybe it's some magic in 
the processor deactivating some cores and the kernel scheduling work to 
the wrong core. Nevertheless my system under test was otherwise idle. I 
booted a minimal initramfs based system with no services at all but the 
ability to load the tcrypt module.

Maybe Huang Ying can give us some insight why the numbers do vary that 
much? My test case was 'modprobe tcrypt mode=200 sec=10' (for latter 
tests I reduces the sec parameter to 1 in favor of doing multiple runs). 
If that's an inappropriate test for the Intel AES instructions maybe 
somebody can tell me how to do better? Maybe dd to a cryptoloop device?

Regards,
Mathias
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Kernel]     [Gnu Classpath]     [Gnu Crypto]     [DM Crypt]     [Netfilter]     [Bugtraq]

Add to Google