> You mean for IPsec, or for SSL?
>
> To benefit from hardware acceleration with IPSec, one really *has* to
> replace the procedurally-coded (blocking) crypto calls in the KAME
> code, with a continuation-passing model.
>
> Sam Leffler has ported OpenBSD's in-kernel, continuation-passing
> crypto (framework, pci drivers, kthread for
> non-accelerated/software-only ops) to FreeBSD, and reworked FreeBSD's
> KAME snapshot to work with it.  I have a bastard tree (part FreeBSD,
> part NetBSD) currently working with a deriviative of Sam's code, and a
> bcm582x board.
>

To clarify a bit; what I did was initially port the openbsd crypto stuff
in-tact.  Then I took a copy of the KAME IPsec and reworked it until it was
capable of using the crypto api.  This involved massive changes and
basically results in a new IPsec that looks more like openbsd's IPsec
smushed together with the KAME netkey+pfkeyv2 code.  Not pretty but it
works.  Finally I dropped the final result into freebsd in such a way that
there was minimal change to the existing KAME code.  The result is two
side-by-side IPsec implementations that you can configure on an either-or
basis.  This lets folks try out my IPsec on an experimental basis while not
losing the existing KAME support.  Note however that my code is
unfinished--there is no IPv6 suport (yet).

FWIW the freebsd version of the crypto code has some differences from
openbsd that you may want to look at carefully.  In particular I handle
resource exhaustion in the crypto drivers differently and am also
MP-ready(not a big deal).

> It wouldn't be too hard to drop either that (or the OpenBSD original)
> into NetBSD.  Gotcha #1: FreeBSD/OpenBSD code now uses packet tags,
> rather than the untyped m_pkthdr "aux" mbuf field.
>

Going back to the openbsd code would certainly resolve some grotty issues
that exist because I tried to preserve as much of the KAME code as possible,
but I think you'd find it's a lot more work.  It's a bit of a tarbaby in
that you'll start dragging in lots of changes that you may not expect and/or
want.  For example, are you ready to redo the routing table to include SP's?

As to packet tags vs aux mbufs; this is really a no-brainer.  aux mbufs are
just abusing mbufs for general purpose memory allocation.  mbuf tags cleanup
various issues in the use of aux mbufs and ease the importing of either my
ipsec code or openbsd's.

> We'd have to either revert theOpenBSD/FreeBSd code to the old
> aux-based style of business; or move -current forward to use packet
> tags.  Since OpenBSD and FreeBSD now use packet tags, going to packet
> tags probably makes most esense for KAME in the medium (or even short)
term.
>

I'm obviously of the opinion that importing mtags is a good thing.

> Gotcha #2: do we want to buy into the OpenBSD crypto(9) API lock,
> stock and barrel?  There was some discussion, early summer, about a
> more general in-kernel crypto API; I dont know if anything came of it.
>

I like to look at it as saving yourself a LOT (and I do mean a lot) of work.
Having a common in-kernel API means you can import crypto drivers.  Also if
you provide a common /dev/crypto interface then you can share the work
that's been done to make openssl /dev/crypto-aware.  This gets you
hardware-accelerated user applications like ssh.

    Sam