Re: GSoc2010 project suggestion: swcryptX

Hi,

On Mon, 22 Feb 2010, Thor Lancelot Simon wrote:
>>    This is where it gets fishy. ;) The existing opencrypto(4) framework
>>    probably needs to be make MP-aware at the same time, employing proper use
>>    of NetBSD's locking framework.
>
> You should read the existing code much more carefully before making this
> kind of lengthy proposal.  Most of what is proposed here is already done
> (allowing multiple CPUs to enter the various opencrypto components,
> including swcrypto, at the same time; converting opencrypto to modern
> locking).
>
> If you believe it's not, let's talk about the code.

You dig into the "MP-aware" part of my suggested project here, but I'm not 
sure if you read the rest - as far as the "MP-aware" part goes, this was 
probably bad wording on my side.

From my understanding of the code, opencrypto(9) spawns 1 kernel thread 
which then handles the actual crypto requests (crypto.c, crypto_init0() 
and cryptoret()). If a second opencrypto(9) call arrives while the first 
one is being handled, it is queued, and processed later 
(crypto_dispatch()).

The idea of my proposal is to make sure that more than one kernel thread 
exists to pick up such requests. I apologize for using the same 
terminology here.

As for the MP-safe part, have a look at the interaction of opencrypto(9) 
and rnd(9) in PR kern/42656, but this is not related here.


> The rest seems to me to be of questionable value, particularly
> jamming a heavy request-scheduling layer into the middle of the framework.
> I know Sam proposed this in the comments in his original code, but I would
> need to be persuaded via benchmarks that it could actually pay off.

I'm not sure more heavy request-scheduling is needed than is already 
there: Multiple providers of one crypto algorithms are already supported, 
and there is code to skip busy ones when issuing a new session (crypto.c, 
crypto_newsession()). I don't think much more is needed - just have each 
CPU that runs an swcrypto thread register their algorithms independently, 
and the existing code will pick up a free provider.

As for the "questionable" part: I agree that the suggested approach is 
pretty silly if you have a multithreaded userspace application - just run 
the crypto software in userland, and be fine. But there are in-kernel 
applications like IPsec, too, and only benchmarks will show if a specific 
application benefits from what I propose.

But for that the code has to be there first. :)


> I do think there are opencrypto-related projects that would be good
> candidates for SoC.  I don't think what you have proposed here is one.  I
> have listed several on the Wiki GSoc page...

I think they make sense, but they also require special and expensive 
hardware, where the idea behind my proposal is that you can get away 
without that to some extent.


  - Hubert