On Mon, Nov 19, 2012 at 5:18 PM, Ian Goldberg iang@cs.uwaterloo.ca 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@torproject.org 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/Multithreaded...
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.