crypto: qce - use AES fallback for small requests
authorEneas U de Queiroz <cotequeiroz@gmail.com>
Fri, 7 Feb 2020 15:02:26 +0000 (12:02 -0300)
committerHerbert Xu <herbert@gondor.apana.org.au>
Thu, 13 Feb 2020 09:05:27 +0000 (17:05 +0800)
commitce163ba0bf298f1707321ac025ef639f88e62801
tree0d5548b88ef4c1cecf98435d66893d6770e17836
parentd6364b8128439a8c0e381f80c38667de9f15eef8
crypto: qce - use AES fallback for small requests

Process small blocks using the fallback cipher, as a workaround for an
observed failure (DMA-related, apparently) when computing the GCM ghash
key.  This brings a speed gain as well, since it avoids the latency of
using the hardware engine to process small blocks.

Using software for all 16-byte requests would be enough to make GCM
work, but to increase performance, a larger threshold would be better.
Measuring the performance of supported ciphers with openssl speed,
software matches hardware at around 768-1024 bytes.

Considering the 256-bit ciphers, software is 2-3 times faster than qce
at 256-bytes, 30% faster at 512, and about even at 768-bytes.  With
128-bit keys, the break-even point would be around 1024-bytes.

This adds the 'aes_sw_max_len' parameter, to set the largest request
length processed by the software fallback.  Its default is being set to
512 bytes, a little lower than the break-even point, to balance the cost
in CPU usage.

Signed-off-by: Eneas U de Queiroz <cotequeiroz@gmail.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
drivers/crypto/Kconfig
drivers/crypto/qce/skcipher.c