wbrawner/openssl
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Lower PADLOCK_CHUNK till value, which doesn't affect the benchmark results.

Browse source 
Well, it's even contrary, 512 was observed to *improve* performance by 5%.
Excuse ourselves from treating C7 specially.
This commit is contained in:
Andy Polyakov 2005-12-27 21:21:56 +00:00
parent ee8f293701
commit 6c06918ede
1 changed files with 6 additions and 1 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

7
crypto/engine/eng_padlock.c
View file

@ -878,7 +878,7 @@ padlock_aes_cipher_omnivorous(EVP_CIPHER_CTX *ctx, unsigned char *out_arg,
}
#ifndef PADLOCK_CHUNK
# define PADLOCK_CHUNK 4096 /* Must be a power of 2 larger than 16 */
# define PADLOCK_CHUNK 512 /* Must be a power of 2 larger than 16 */
#endif
#if PADLOCK_CHUNK<16 || PADLOCK_CHUNK&(PADLOCK_CHUNK-1)
# error "insane PADLOCK_CHUNK..."
@ -905,6 +905,11 @@ padlock_aes_cipher(EVP_CIPHER_CTX *ctx, unsigned char *out_arg,
/* VIA promises CPUs that won't require alignment in the future.
For now padlock_aes_align_required is initialized to 1 and
the condition is never met... */
/* C7 core is capable to manage unaligned input in non-ECB[!]
mode, but performance penalties appear to be approximately
same as for software alignment below or ~3x. They promise to
improve it in the future, but for now we can just as well
pretend that it can only handle aligned input... */
if (!padlock_aes_align_required)
return padlock_aes_cipher_omnivorous(ctx, out_arg, in_arg, nbytes);