Krishna Yenduri wrote:
> On 08/25/09 05:05, Vladimir Kotal wrote:
>> ...
>> The results of the AES microbenchmark runs (5 repetitions of each
>> test) on T5220 machine (64 HW threads, each 1167MHz) are rather
>> interesting:
>
> The single thread performance number is the important one
> because we are worried about the latency here.
>
> The AES 64 test uses AES software provider because it falls under
> the 512-byte threshold. So, we don't see any regression as expected. I
> think
> the slight improvement could be from other factors like the cache.
Ah, stupid me. I got so focused on executing the tests correctly only to
forget about the threshold.
<snip>
> This could be because of the cache or the variation in thread scheduling.
> In any case, this fix does not add any locking. So, it is OK to let this
> pass.
Thanks.
Also, I did some minor last minute changes:
- added a comment to kcf_check_prov_mech_keylen() explaining the
reasons for returning 1
- changed DES_MINBITS in des_crypt.c to DES_MAXBITS when checking
- effectively a NOP because those 2 constants are equal; changed
only for consistency with the rest of des_common_init()
Incremental webrev of these changes:
http://cr.opensolaris.org/~vkotal/kcf-keylen_check-6786946.onnv.nits/
Final webrev is here:
http://cr.opensolaris.org/~vkotal/kcf-keylen_check-6786946.onnv.final/
v.
