Crypto IOV/non-IOV code consolidation

[Greg Hudson]

On Sun, 2009-11-29 at 18:48 -0500, Greg Hudson wrote:
> I tried this, and the performance penalty seems to be noticeable--around
> 15% for encrypt and 20% for decrypt, for 100-byte messages.  (Decrypt
> has to copy both the input and the output, so it carries a larger
> penalty.)

I made a couple of optimizations here after which the performance
penalty drops to the noise level, depending on enctype and workload.
The main change is using a couple of inline functions in aead.h to
quickly handle the case where the next block is within the current
buffer.

> A notable obstacle here is that we don't have IOV implementations for
> the des-cbc-crc, des-cbc-md4, and des-hmac-sha1 enctypes, or for the
> descbc, md4des, md5des, and md5_hmac keyhash providers.

I implemented an AEAD provider for the des enctypes.

I took a stab at implementing input/output iov parameters for the AEAD
paths.  This is easy to do at the enc_provider level, but at the token
level it gets ugly very quickly.  For example, the arcfour token
encryption function needs to advance the header buffer past the checksum
so that the correct part of the header gets encrypted, and then revert
it afterwards.  That's pretty tough to do when you might or might not
have separate input/output iovs.

I also ran some tests and determined that copying the input has a pretty
minimal impact on performance.  I think I can safely go ahead and
consolidate the iovec/non-iovec code using the existing IOV interfaces.