Re: [tor-dev] Parallel Crypto - Library dep.

[David Goulet <dgoulet@xxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12-01-31 03:42 PM, Nick Mathewson wrote:
> On Tue, Jan 31, 2012 at 2:46 PM, David Goulet <dgoulet@xxxxxxxxx> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> 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!
David

> cheers,
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAEBAgAGBQJPKJo3AAoJEELoaioR9I02Yt8IAJXv4pgj53jhAtqlMX4DfmpX
SCu/Vnx3+JUFsS1VgJkXXcA1f4pQNNJasoTHcjXDU7eJD2LD/sWkfbM9FrW1vwgd
WjpNwRk0WFFQDZFHULjg72iftEVbLEJNjDhsvX0U/YHwHqgm+OVvoUHEwe22kON1
4peqyGyrem8lutaKA9+SLXhEC7U44Tn7tUqCUj9rWZAtAcCH0AE8baNPiHShNWYx
Av+ddnrCt3Pcpo3KZzVK5ZU7D4Ub7/rolyH4T5FjMm0ukmNv+gAjxfDQpqhzFA0h
Go92OHHno8kB74hsmMDIVCljUbRMbBn/vOMWPpWmvEiYJD6ofC9neV1qnbjhT7s=
=lagt
-----END PGP SIGNATURE-----
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev