Re: GSoc2010 project suggestion: swcryptX

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

On Tue, Feb 23, 2010 at 03:26:36PM -0800, Jason Thorpe wrote:
> 
> I'm skeptical.  If a particular thread of execution has to wait for the
> crypto to happen anyway, let it do it work itself.

Well, right.  The architecturally better (but harder) project here would
be to make it possible for multiple CPUs to execute in the netipsec code
at the same time.

That's probably not as hard as it might at first seem because this is
_under_ the really problematic layer, TCP.  But it is not trivial either.

The problem is that the entire win from the kind of work on cryptosoft that's
proposed for this project comes from making cryptosoft defer requests and
its caller, fast_ipsec, yield.  But there are probably more environments
where yielding like that loses than where it wins.  In the hardware-crypto
case, you win because the special-purpose processor can't _do_ anything else
so you might as well let it and the general-purpose processor work at the
same time.  In the software-crypto case, you win if and only if there is
really nothing else either general-purpose processor could do in the time
it takes to do one crypto operation plus two thread switches.

I actually think one case where this kind of always-queueing cryptosoft
implementation might win would be cgd.

Thor