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.

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.

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.

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.