GSoc2010 project suggestion: swcryptX

[Hubert Feyrer <hubert%feyrer.de@localhost>]

I've been thinking about speeding up crypto following the previous 
discussion, and would like to propose offering the following project for 
this year's Google Summer of Code:

     Abstract: The goal of this project is to provide crypto acceleration by
     utilizing multiple CPU cores. The work is to extend the existing
     software-only "swcrypto" crypto driver and hook that up with NetBSD's
     OpenCrypto framework. Work is expected to make the opencrypto(9)
     framework itself MP-safe.

Overview of operation

   The opencrypto(9) framework exists to coordinate hardware acceleration in
   NetBSD. Applications of the framework can be inside the kernel like the
   FAST_IPSEC IPsec implementation, or in userland like OpenSSL with the
   "cryptodev" engine. Crypto drivers can be realized in software or in
   hardware. Hardware drivers can be used to instruct e.g. the AMD Geode LX's
   AES block or a HIFN chip to perform cryptographic operations. Upon system
   startup, the crypto drivers at the opencrypto(9) framework, telling what
   operations they can perform. When an operation is required later, the
   framework will look which crypto device is currently not busy, and offload
   the operation to that device. Upon completion, the result is fed back to
   the application.

   The image at [1] illustrates the components and their interaction.

Limitations

   Offloading the cryptographic requests involves some overhead. Data needs
   to be transferred to the hardware and back. On systems with a slow CPU,
   this overhead is relatively small compared to the operation speed of the
   CPU. On faster CPUs, the overhead becomes more of a burden, making the
   benefit of the crypto hardware negligible.

   As examples, while a hifn(4) chip can provide worthwhile speedups on
   500MHz and 1GHz CPUs, no performance win is experienced on a 2.4GHz CPU.

Proposal

   The communication overhead involves data transfers over a PCI bus, which
   is of relatively low speed compared to today's modern CPUs. Preventing the
   data transfer is a worthwhile goal. In coordination with today's modern
   multi-core CPUs, using one or more CPUs solely for the purpose of crypto
   acceleration, a measurable improvement of crypto performance is expected.
   At the same time, no special hardware requirements beyond the CPU exist.
   This allows turning standard contemporary systems into fast crypto systems
   easily.

   The image at [2] illustrates the idea of interoperation between a CPU

   core that runs the kernel and application codes and three cores that are
   dedicated to crypto code.

Implementation Roadmap

   This is where it gets fishy. ;) The existing opencrypto(4) framework
   probably needs to be make MP-aware at the same time, employing proper use
   of NetBSD's locking framework. The existing swcrypto(4) needs to be
   adjusted for operation on multiple CPUs at the same time. A way to decide
   how many CPUs are dedicated to run swcrypto(4) instances. CPUs that run
   swcrypto(4) need to be taken out from the usual NetBSD CPU scheduling so
   that they are available exclusively for crypto.

Requirements

   In no particular order:
     * Know how to build and install a kernel
     * Understanding of fine grained SMP and locking
     * How to use NetBSD's kernel threads, code-wise
     * How to interact with NetBSD's scheduler, code-wise
     * Tell the scheduler to pin a specific kernel thread to a specific CPU
     * Interaction between applications (IPsec, OpenSSL) with opencrypto(9),
       code-wise
     * Interaction of crypto providers with opencrypto(9), code-wise
     * Hardware! You won't be able to do this without at least two CPU cores
       in your machine. The more the better.
     * Benchmarking & a test setup for it

Project Applications

   Please follow the NetBSD Project Application/Proposal HowTo[3] if
   you're serious to work on this project.

   If you have any questions let me know, public discussion should be led
   on the tech-crypto@ list.

[1] http://www.feyrer.de/NetBSD/images/gsoc2010-swcryptX-1.png
[2] http://www.feyrer.de/NetBSD/images/gsoc2010-swcryptX-2.png
[3] http://www.netbsd.org/contrib/soc-application.html



P.S.: I'm not really in a position to mentor this. Mentors welcome! :)
P.P.S.: This proposal is also available at
        http://www.feyrer.de/NetBSD/gsoc2010-swcryptX.html