Current-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: GSoc2010 project suggestion: swcryptX


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

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

Home | Main Index | Thread Index | Old Index