On Fri, Jun 29, 2018 at 05:01:40PM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> I found that not only was sha256_mb sometimes computing the wrong digest
> (fixed by a separately sent patch), but under normal workloads it's
> hundreds of times slower than sha256-avx2, due to the flush delay. The
> same applies to sha1_mb and sha512_mb. Yet, currently these can be the
> highest priority implementations and therefore used by default.
> Therefore, this series decreases their priority so that users have to
> more explicitly opt-in to using them.
>
> Note that I don't believe the status quo of just having them behind
> kernel config options is sufficient, since people often aren't familiar
> with all the crypto options and error on the side of enabling too many.
> And it's especially unexpected that enabling an "optimized"
> implementation would actually make things 1000 times slower.
>
> Eric Biggers (4):
> crypto: sha1_generic - add cra_priority
> crypto: sha256_generic - add cra_priority
> crypto: sha512_generic - add cra_priority
> crypto: x86/sha-mb - decrease priority of multibuffer algorithms
>
> arch/x86/crypto/sha1-mb/sha1_mb.c | 9 -
> arch/x86/crypto/sha256-mb/sha256_mb.c | 9 -
> arch/x86/crypto/sha512-mb/sha512_mb.c | 9 -
> crypto/sha1_generic.c | 1 +
> crypto/sha256_generic.c | 2 ++
> crypto/sha512_generic.c | 2 ++
> 6 files changed, 29 insertions(+), 3 deletions(-)
All applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
