Re: glxsb(4) and other opencrypto(9) engines in use by cgd(4) and fast_ipsec(4) ?

[Thor Lancelot Simon <tls%rek.tjls.com@localhost>]

On Wed, Sep 17, 2008 at 10:15:07AM -0400, Brian A. Seklecki wrote:
> Couple of crypto(9) related questions:
> 
> 1) We're revisiting they way we deploy CGD systems.  I have a note from
>    last year (can't find the referencing e-mail) about how certain
>    kernel-level systems (ipsec and CGD) weren't yet utilizing opencrypto
>    engines, including hardware accelerators?

Don't confuse "options IPSEC" (the KAME IPsec, slated for eventual removal)
with "options FAST_IPSEC", which will use hardware accelleration if present.

Hardware will be used in preference to software.  However, be aware that a
number of the hardware drivers are either grossly inefficient (e.g. copying
every byte handled for no reason -- usually because their structure has been
borrowed from cryptosoft) or don't actually support the full set of transforms
supported by the hardware.  Unfortunately, the support for the ubiquitous
VIA crypto instructions loses on both counts, as I recall.

You're correct that the cgd driver doesn't use crypto(9).  It could -- if it
did so synchronously (waiting on every request) the modifications would be
quite small.  However, someone ought to replace the dreadful iovec-walking
code used by crypto(9) with the considerably better code in cgd -- or even
better yet, something that submits multiple requests but doesn't copy at
all -- while they're at it, at least so I says.

Making cgd use crypto(9) *asynchronously* could be a big win even in the
software case, particularly on multiprocessors.  However, that would
probably require more restructuring of the code.

Thor