1. 25 2月, 2012 4 次提交
  2. 14 2月, 2012 2 次提交
  3. 13 1月, 2012 3 次提交
  4. 20 12月, 2011 2 次提交
  5. 21 11月, 2011 5 次提交
  6. 09 11月, 2011 2 次提交
    • J
      crypto: twofish-x86_64-3way - add xts support · bae6d303
      Jussi Kivilinna 提交于
      Patch adds XTS support for twofish-x86_64-3way by using xts_crypt(). Patch has
      been tested with tcrypt and automated filesystem tests.
      
      Tcrypt benchmarks results (twofish-3way/twofish-asm speed ratios):
      
      Intel Celeron T1600 (fam:6, model:15, step:13):
      
      size    xts-enc xts-dec
      16B     0.98x   1.00x
      64B     1.14x   1.15x
      256B    1.23x   1.25x
      1024B   1.26x   1.29x
      8192B   1.28x   1.30x
      
      AMD Phenom II 1055T (fam:16, model:10):
      
      size    xts-enc xts-dec
      16B     1.03x   1.03x
      64B     1.13x   1.16x
      256B    1.20x   1.20x
      1024B   1.22x   1.22x
      8192B   1.22x   1.21x
      Signed-off-by: NJussi Kivilinna <jussi.kivilinna@mbnet.fi>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      bae6d303
    • J
      crypto: twofish-x86_64-3way - add lrw support · 81559f9a
      Jussi Kivilinna 提交于
      Patch adds LRW support for twofish-x86_64-3way by using lrw_crypt(). Patch has
      been tested with tcrypt and automated filesystem tests.
      
      Tcrypt benchmarks results (twofish-3way/twofish-asm speed ratios):
      
      Intel Celeron T1600 (fam:6, model:15, step:13):
      
      size	lrw-enc	lrw-dec
      16B	0.99x	1.00x
      64B	1.17x	1.17x
      256B	1.26x	1.27x
      1024B	1.30x	1.31x
      8192B	1.31x	1.32x
      
      AMD Phenom II 1055T (fam:16, model:10):
      
      size	lrw-enc	lrw-dec
      16B	1.06x	1.01x
      64B	1.08x	1.14x
      256B	1.19x	1.20x
      1024B	1.21x	1.22x
      8192B	1.23x	1.24x
      Signed-off-by: NJussi Kivilinna <jussi.kivilinna@mbnet.fi>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      81559f9a
  7. 01 11月, 2011 1 次提交
  8. 21 10月, 2011 6 次提交
  9. 22 9月, 2011 2 次提交
  10. 10 8月, 2011 1 次提交
    • M
      crypto: sha1 - SSSE3 based SHA1 implementation for x86-64 · 66be8951
      Mathias Krause 提交于
      This is an assembler implementation of the SHA1 algorithm using the
      Supplemental SSE3 (SSSE3) instructions or, when available, the
      Advanced Vector Extensions (AVX).
      
      Testing with the tcrypt module shows the raw hash performance is up to
      2.3 times faster than the C implementation, using 8k data blocks on a
      Core 2 Duo T5500. For the smalest data set (16 byte) it is still 25%
      faster.
      
      Since this implementation uses SSE/YMM registers it cannot safely be
      used in every situation, e.g. while an IRQ interrupts a kernel thread.
      The implementation falls back to the generic SHA1 variant, if using
      the SSE/YMM registers is not possible.
      
      With this algorithm I was able to increase the throughput of a single
      IPsec link from 344 Mbit/s to 464 Mbit/s on a Core 2 Quad CPU using
      the SSSE3 variant -- a speedup of +34.8%.
      
      Saving and restoring SSE/YMM state might make the actual throughput
      fluctuate when there are FPU intensive userland applications running.
      For example, meassuring the performance using iperf2 directly on the
      machine under test gives wobbling numbers because iperf2 uses the FPU
      for each packet to check if the reporting interval has expired (in the
      above test I got min/max/avg: 402/484/464 MBit/s).
      
      Using this algorithm on a IPsec gateway gives much more reasonable and
      stable numbers, albeit not as high as in the directly connected case.
      Here is the result from an RFC 2544 test run with a EXFO Packet Blazer
      FTB-8510:
      
       frame size    sha1-generic     sha1-ssse3    delta
          64 byte     37.5 MBit/s    37.5 MBit/s     0.0%
         128 byte     56.3 MBit/s    62.5 MBit/s   +11.0%
         256 byte     87.5 MBit/s   100.0 MBit/s   +14.3%
         512 byte    131.3 MBit/s   150.0 MBit/s   +14.2%
        1024 byte    162.5 MBit/s   193.8 MBit/s   +19.3%
        1280 byte    175.0 MBit/s   212.5 MBit/s   +21.4%
        1420 byte    175.0 MBit/s   218.7 MBit/s   +25.0%
        1518 byte    150.0 MBit/s   181.2 MBit/s   +20.8%
      
      The throughput for the largest frame size is lower than for the
      previous size because the IP packets need to be fragmented in this
      case to make there way through the IPsec tunnel.
      Signed-off-by: NMathias Krause <minipli@googlemail.com>
      Cc: Maxim Locktyukhin <maxim.locktyukhin@intel.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      66be8951
  11. 30 6月, 2011 1 次提交
  12. 18 5月, 2011 1 次提交
  13. 16 5月, 2011 1 次提交
  14. 27 3月, 2011 1 次提交
  15. 18 3月, 2011 1 次提交
  16. 16 2月, 2011 1 次提交
  17. 23 1月, 2011 1 次提交
    • J
      crypto: aesni-intel - Don't leak memory in rfc4106_set_hash_subkey · 7efd95f6
      Jesper Juhl 提交于
      There's a small memory leak in 
      arch/x86/crypto/aesni-intel_glue.c::rfc4106_set_hash_subkey(). If the call 
      to kmalloc() fails and returns NULL then the memory allocated previously 
      by ablkcipher_request_alloc() is not freed when we leave the function.
      
      I could have just added a call to ablkcipher_request_free() before we 
      return -ENOMEM, but that started to look too much like the code we 
      already had at the end of the function, so I chose instead to rework the 
      code a bit so that there are now a few labels at the end that we goto when 
      various allocations fail, so we don't have to repeat the same blocks of 
      code (this also reduces the object code size slightly).
      Signed-off-by: NJesper Juhl <jj@chaosbits.net>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      7efd95f6
  18. 15 12月, 2010 1 次提交
  19. 13 12月, 2010 1 次提交
  20. 29 11月, 2010 1 次提交
  21. 27 11月, 2010 1 次提交
    • M
      crypto: aesni-intel - Ported implementation to x86-32 · 0d258efb
      Mathias Krause 提交于
      The AES-NI instructions are also available in legacy mode so the 32-bit
      architecture may profit from those, too.
      
      To illustrate the performance gain here's a short summary of a dm-crypt
      speed test on a Core i7 M620 running at 2.67GHz comparing both assembler
      implementations:
      
      x86:                   i568       aes-ni    delta
      ECB, 256 bit:     93.8 MB/s   123.3 MB/s   +31.4%
      CBC, 256 bit:     84.8 MB/s   262.3 MB/s  +209.3%
      LRW, 256 bit:    108.6 MB/s   222.1 MB/s  +104.5%
      XTS, 256 bit:    105.0 MB/s   205.5 MB/s   +95.7%
      
      Additionally, due to some minor optimizations, the 64-bit version also
      got a minor performance gain as seen below:
      
      x86-64:           old impl.    new impl.    delta
      ECB, 256 bit:    121.1 MB/s   123.0 MB/s    +1.5%
      CBC, 256 bit:    285.3 MB/s   290.8 MB/s    +1.9%
      LRW, 256 bit:    263.7 MB/s   265.3 MB/s    +0.6%
      XTS, 256 bit:    251.1 MB/s   255.3 MB/s    +1.7%
      Signed-off-by: NMathias Krause <minipli@googlemail.com>
      Reviewed-by: NHuang Ying <ying.huang@intel.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      0d258efb
  22. 13 11月, 2010 1 次提交