Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • Trac Trac
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Issues 246
    • Issues 246
    • List
    • Boards
    • Service Desk
    • Milestones
  • Monitor
    • Monitor
    • Metrics
    • Incidents
  • Analytics
    • Analytics
    • Value stream
  • Wiki
    • Wiki
  • Activity
  • Create a new issue
  • Issue Boards
Collapse sidebar
  • Legacy
  • TracTrac
  • Issues
  • #24448
Closed (moved) (moved)
Open
Issue created Nov 27, 2017 by David Goulet@dgoulet🐼

Channeltls adds the connection write event to main loop when writing a packed cell

This is another problem in the line of channel subsystem and KIST. It is a difficult problem because tor is wired to use libevent connection's write and read event where KIST needs to control what is put on the network at what time.

So, here is the callstack that leads to the channeltls layer adding the conn->write_event to the main loop:

channel_tls_write_packed_cell_method()
 -> connection_buf_add()
   -> connection_write_to_buf_commit()
     -> connection_start_writing()
       -> event_add(conn->write_event, NULL)

Basically, when we flush cell(s) from a circuit, we do call back into the channel subsystem to write the packed cell (only packed cell on a circuit queue). The libevent write event is then added to the main loop. Then KIST scheduler kicks in a tick later (10 ms) and can also try to write.

I don't see a direct impact here but we could avoid an entire "write_event" callback on a connection with the KIST scheduler which seems to me like a good optimization especially on fast relays.

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking