[tor-dev] Parallel relaycrypt data structures for review
nickm at freehaven.net
Fri Nov 30 13:12:10 UTC 2012
On Nov 29, 2012 9:30 PM, "Andrea Shepard" <andrea at torproject.org> wrote:
> Please review first draft proposed parallel relaycrypt structures
> in my parallel_relay_crypt branch.
Hi! Here are some initial thoughts:
* If we're going to do it like this, maybe we need to make cell_t
packed or something eventually. It's got a fair amount of padding
overhead right now.
* Maybe we'll need a next pointer in cells if we're queueing them?
* Why is there only an rc_job for outgoing cells on a circuit? It
seems for symmetry we'd need to have one for inbound cells and one for
outbound cells. It looks like that code isn't there right now?
* Maybe I'm confused by these queues. The system of cell queues is
going to get a little confusing, maybe. Putting cells on the outgoing
queue isn't always right, since some cells (e.g., relay_data cells at
an exit node) need to be handled locally rather than relaying them.
So we need more new queues?
* Should the jobs be in some data structure other than an smartlist_t?
A queue would seem to make more sense, since jobs are getting added
and pulled off. (Yes, protecting the data structure there with a lock
* If you're going to have separate locks, it's important to document
how they nest, to prevent deadlock conditions.
* Presumably relaycrypt_job_t would need to have a pointer to the
actual circuit that needs work, and a note about whether it's a job
for outbound or inbound cells.
* In the non-threaded-relaycrypt case, presumably the intention is
that there's a function that would otherwise queue a cell for crypto
but instead just put it directly on the appropriate circuit queue?
Thanks again! I'll let you know if I think of anything else.
More information about the tor-dev