1. 22 Feb, 2020 38 commits
  2. 13 Feb, 2020 2 commits
    • Eneas U de Queiroz's avatar
      crypto: qce - handle AES-XTS cases that qce fails · 7f19380b
      Eneas U de Queiroz authored
      QCE hangs when presented with an AES-XTS request whose length is larger
      than QCE_SECTOR_SIZE (512-bytes), and is not a multiple of it.  Let the
      fallback cipher handle them.
      Signed-off-by: default avatarEneas U de Queiroz <cotequeiroz@gmail.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      7f19380b
    • Eneas U de Queiroz's avatar
      crypto: qce - use AES fallback for small requests · ce163ba0
      Eneas U de Queiroz authored
      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: default avatarEneas U de Queiroz <cotequeiroz@gmail.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      ce163ba0