[tor-bugs] #9574 [Tor]: Process ntor create cells before tap create cells?

Tor Bug Tracker & Wiki blackhole at torproject.org
Wed Sep 4 12:41:42 UTC 2013


#9574: Process ntor create cells before tap create cells?
-----------------------------+---------------------------------------
     Reporter:  arma         |      Owner:
         Type:  enhancement  |     Status:  needs_review
     Priority:  normal       |  Milestone:  Tor: 0.2.4.x-final
    Component:  Tor          |    Version:
   Resolution:               |   Keywords:  tor-relay, maybe-proposal
Actual Points:               |  Parent ID:  #9657
       Points:               |
-----------------------------+---------------------------------------

Comment (by iang):

 Replying to [comment:29 arma]:
 > Replying to [comment:6 iang]:
 > > I also noticed a little while ago that the way the TAP cells are
 currently farmed out to cpuworkers may not be the most efficient way we
 could do things.  There are quite a few system calls happening for each
 TAP cell right now; something more clever could surely be done.  With
 ntor, the system call overhead would likely be a substantial fraction of
 the total processing time.  But, as above, this would be a separate
 ticket.
 >
 > Ian, can you explain in some more detail? We should explore doing this
 in 0.2.5. If you have enough details to have a concrete suggestion, please
 make a new ticket out of it.
 >
 > Thanks!

 It's been a little bit since I last looked at that code, but from what I
 remember, the create cells are written to one of n sockets, where n is the
 number of cpuworkers.  Each cpuworker reads its end of the socket to get
 the data out, processes it, and writes the response back to the socket.

 I have a feeling the system calls involved in the
 write/select/read/write/select/read may be taking a nontrivial amount of
 time.  (But I emphasize that I did not measure this in any way.)  If we're
 threading (as opposed to forking), we'll be in the same memory space, and
 something with semaphore-controlled processing of a shared data structure
 (or something like that) is likely to be faster (but perhaps not simpler).

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/9574#comment:31>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online


More information about the tor-bugs mailing list