Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
Trac
Trac
  • Project overview
    • Project overview
    • Details
    • Activity
  • Issues 246
    • Issues 246
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Operations
    • Operations
    • Metrics
    • Incidents
  • Analytics
    • Analytics
    • Value Stream
  • Wiki
    • Wiki
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Create a new issue
  • Issue Boards

GitLab is used only for code review, issue tracking and project management. Canonical locations for source code are still https://gitweb.torproject.org/ https://git.torproject.org/ and git-rw.torproject.org.

  • Legacy
  • TracTrac
  • Issues
  • #24449

Closed (moved)
Open
Opened Nov 27, 2017 by David Goulet@dgoulet🐋

sched: KIST scheduler should handle limited or failed connection write

This is specific to KIST as far as I can tell.

KIST will flush cells one by one from the circuit queue to the outbuf as long as the socket TCP limit allows it. Now, I've seen on a normal relay using KIST flushing 164 cells at once onto the outbuf. This is fine, it is only 83968 bytes.

Then, at some point, it will write to the kernel with connection_handle_write(conn, 0). The returned value is ignored which is not good because that function will limit the number of bytes written to up to a maximum of ~8KB (~16 cells):

  max_to_write = force ? (ssize_t)conn->outbuf_flushlen
    : connection_bucket_write_limit(conn, now);

We do not call the function with force = 1 which would make us flush them all. And we probably don't want to do that because force=0 is respecting our bandwidth rate if any.

So, I think we might want to have KIST to be a bit more wise here and on a per-channel basis, decide on a maximum number of cells it can flush which would respect our bucket size and priority?

To upload designs, you'll need to enable LFS and have admin enable hashed storage. More information
Assignee
Assign to
Tor: unspecified
Milestone
Tor: unspecified
Assign milestone
Time tracking
None
Due date
None
Reference: legacy/trac#24449