On Thu, 2007-08-30 at 11:38 -0400, Dan McDonald wrote:
> On Thu, Aug 30, 2007 at 08:31:11AM -0400, Sebastien Roy wrote:
> <SNIP!>
> > That said, there are some things that Nemo doesn't do today that would
> > prevent its replacing DLPI. The DL_NOTIFY_* and DL_CAPABILITY_*
> > mechanisms are two I'm thinking of, and there may be others.
>
> One use of these is IPsec HW acceleration. I know of a least one driver
> writer (who wishes to remain anonymous) who's thinking about taking his/her
> driver for his/her nifty IPsec-accelerating card (kinda like our discontinued
> SCA 4000) and get it running on OpenSolaris. I told him/her to look at what
> we had for use with the old SCA 4k as a starting point.
>
> SOMEDAY it might be nice to have a Nemo equivalent for more
> industrial-strength offloads. I don't want to necessarily go down the whole
> TOE path, but I think about how much CPU crypto sucks down.
It seems like we could make NEMO provide the same crypto offload
support. I agree that doing IPsec in software really, really sucks.
Even the offload to a separate crypto engine kind of sucks, because it
means pushing around packets across the bus multiple times, and the
packets might be tiny, so the overhead of moving them around starts to
get time consuming.
We found that "in-band" processing of IPsec with SCA 4000 was a lot more
efficient. I'd really, really like someday to see this kind of offload
properly supported in the stack, without having to resort to crufty DLPI
mechanisms.
-- Garrett
>
> Dan
> _______________________________________________
> networking-discuss mailing list
> [email protected]
_______________________________________________
networking-discuss mailing list
[email protected]
