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