[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
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
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.
Main Index |
Thread Index |