[tor-dev] Parallel Crypto - Library dep.

David Goulet dgoulet at ev0ke.net
Wed Feb 1 01:49:43 UTC 2012

Hash: SHA1

On 12-01-31 03:42 PM, Nick Mathewson wrote:
> On Tue, Jan 31, 2012 at 2:46 PM, David Goulet <dgoulet at ev0ke.net> wrote:
>> Hash: SHA1
>> Hi everyone,
>> To help the tor project, I'll contribute some of my spare time to improve
>> multithreading for the Tor code base.
>> I've speak a bit with Nick M. and it seems the crypto lib is an important part
>> to begin with. The wiki page
>> (https://trac.torproject.org/projects/tor/wiki/org/projects/Tor/MultithreadedCrypto)
>> indicates, basically, that a worker thread pool with a work queue to dispatch
>> crypto events should be the right approach and I do agree.
>> Is it acceptable to link an external library to the project being a dependence?
> It depends, I'd say.  Most of the data structures we're talking about
> here are ones that allow a lockless and locked implementations.  So my
> ideal implementation would be to have the ability to use lockless
> structures where available, but a locked implementation otherwise.
> This would let us work with better lockless libraries if they come
> along, and continue to run on operating systems or on CPUs that don't
> support librcu, and also migrate to another system in the future in
> case a better one comes along.

I do agree on that! However, sometimes APIs from those kind of libs can be quite
complex (if I think about the red-black tree in URCU...) so having compat layer
between lock and lockless is sometime a bit of work.

So going for a wait-free queue and a normal locked queue, it's not that
difficult (in terms of APIs/ABIs handling) but the question I think is do we
want first to do a "normal locking queue" in the tor code tree and than go for a
lockless from a external lib with a compat layer between lock and lockless ?

Personally, I think we should go straight for one type of data structure and
make sure we create a decent compat layer on top to be able to switch from one
technology to an other easily.

Does it makes sense to you?

> But personally, I would be very surprised if this turned out to make a
> very big difference: even symmetric crypto is pretty slow in
> comparison to even the most obvious work-queue implementations, right?
>  (If I'm missing something there, please let me know.)

Well, I'm not too knowledgeable in crypto implementation but if some hardware
can be use to do the job, it will considerably speed up the process so a
situation where your crypto will go faster than queuing events is a possibility
(if I understand the question right).


> cheers,
Version: GnuPG v1.4.10 (GNU/Linux)


More information about the tor-dev mailing list