diff options
author | Eneas U de Queiroz <cotequeiroz@gmail.com> | 2020-02-07 18:02:26 +0300 |
---|---|---|
committer | Herbert Xu <herbert@gondor.apana.org.au> | 2020-02-13 12:05:27 +0300 |
commit | ce163ba0bf298f1707321ac025ef639f88e62801 (patch) | |
tree | 0d5548b88ef4c1cecf98435d66893d6770e17836 /Makefile | |
parent | d6364b8128439a8c0e381f80c38667de9f15eef8 (diff) | |
download | linux-ce163ba0bf298f1707321ac025ef639f88e62801.tar.xz |
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>
Diffstat (limited to 'Makefile')
0 files changed, 0 insertions, 0 deletions