Re: [tor-dev] Parallel relaycrypt data structures for review

[Nick Mathewson <nickm@xxxxxxxxxxxxx>]

On Nov 29, 2012 9:30 PM, "Andrea Shepard" <andrea@xxxxxxxxxxxxxx> 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
makes sense.)

* 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.

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