Re: [tor-dev] Request for comments on notes on parallel cell crypto

[Nick Mathewson <nickm@xxxxxxxxxxxx>]

On Mon, Nov 19, 2012 at 5:18 PM, Ian Goldberg <iang@xxxxxxxxxxxxxxx> wrote:
> On Mon, Nov 19, 2012 at 05:06:58PM -0500, Nick Mathewson wrote:
>> On Sun, Nov 18, 2012 at 7:43 PM, Andrea Shepard <andrea@xxxxxxxxxxxxxx> wrote:
>> > I've made some notes on parallelizing cell crypto on relays which I've
>> > attached to this mail and added to the wiki page on this [1], which I
>> > would like comment on.  Particularly, I want to resolve the following
>> > points:
>> >
>> >  * Should we operate on cell_t or packed_cell_t?
>
> I seem to have missed the original email here.  What is the link [1]?

[1] https://trac.torproject.org/projects/tor/wiki/org/projects/Tor/MultithreadedCrypto


> Having just upgraded my exit node to a reasonable machine, I found that
> even though the AES should be super-fast (with AES-NI, etc.), the
> public-key ops are still killing the CPU.  I split the node into two
> processes, but multithreading the public-key ops (to a configurable
> number of threads, like say 7) would appear to be a big bang-for-buck
> win.

Circuit-related public key should already be parallelized
(configurably, via the NumCPUs option).  Parallelizing most SSL public
key will be a little trickier, though I guess we could farm off
certificate verification and the public key parts of the v3 handshake
to cpuworkers too, with a nontrivial amount of effort.

We once had code that tried to track how many PK operations of each
kind Tor does, for what purpose, so we could figure out which ones
were costing us the most.  We should try to get that working again.
note_crypto_pk_op() is the core function in question -- for some
incomprehensible reason, it would report its results via the directory
port.  Instead, it should probably use the heartbeat code or
something.

Also on the crypto performance front, I'm hoping that enabling ECDHE
ciphersuites for TLS will save some of the time we currently spend on
PK, and that ntor with a good EC group will save some more.

-- 
Nick
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev