Performance of XTS mode using aesni.ko driver is lower than expected. AES-XTS mode is often slower than AES-CBC. Fix: A patch is attached that makes the aesni driver call the assembly routines in crypto/openssl. This at least doubles the current throughput. The attached benchmark output is for an i5-2500, 10.0-current, Clang system with debugging options on. Appplying the patch to stable with gcc results in 16Gbps throughput without maxing out the CPU. Perl will be required to generate the assembly instructions from the scripts in crypto/openssl. Patch attached with submission follows: How-To-Repeat: Benchmark using tools/tools/cryptotest, or perform large file operations on a GEOM_ELI filesystem.
This update removes the perl/openssl dependencies. The c implementation is a drop-in replacement for the existing assembly code. It captures most of the performance of the openssl module, and I still have a few optimizations to try. amd64 only until I get clang to cross compile the module. gcc4.2 lacks the opcodes for the new instructions, but it will compile with gcc47 from ports. The module will compile with -mavx and improves performance in user-space. Shane Nievera Tablizo nievera@mm.st
State Changed From-To: open->feedback I recently did some work on pipelining aes-ni and I'm not sure how applicable your patch is anymore, can you evaluate and maybe we can work together to get even better performance from it? Thanks.
Responsible Changed From-To: freebsd-bugs->jmg forgot to take ownership of this bug..
For bugs matching the following criteria: Status: In Progress Changed: (is less than) 2014-06-01 Reset to default assignee and clear in-progress tags. Mail being skipped
At this point the most likely path forward for this approach is to add AES-XTS support to ossl(4) which already uses assembly routines from OpenSSL from some other ciphers.