[tor-bugs] #23712 [Core Tor/Tor]: sched: DESTROY cell on a circuit bypasses the scheduler
Tor Bug Tracker & Wiki
blackhole at torproject.org
Fri Sep 29 16:27:21 UTC 2017
#23712: sched: DESTROY cell on a circuit bypasses the scheduler
------------------------------+--------------------------------
Reporter: dgoulet | Owner: (none)
Type: defect | Status: new
Priority: Medium | Milestone: Tor: 0.3.2.x-final
Component: Core Tor/Tor | Version:
Severity: Normal | Keywords: tor-sched
Actual Points: | Parent ID:
Points: | Reviewer:
Sponsor: |
------------------------------+--------------------------------
If you look at `circuitmux_append_destroy_cell()`, it is the one appending
a DESTROY cell to the cmux queue and then calls
`channel_flush_from_first_active_circuit()` if no writes are pending that
is if the outbuf is empty (also looks at the out queue but that is always
empty #23709).
In the case the flush is triggered, the cell is immediately put in the
outbuf and written to kernel by libevent which completely bypasses the
scheduler. Maybe it is what we want that is go as fast as we can in
destroying a circuit? Don't know but it has this effect on the scheduler
where the channel is scheduled with a "wants_to_write" event from the
connection subsystem and ultimately the channel gets scheduled with
nothing in the queue because it is already on the outbuf. For KIST, this
is not ideal because KIST should control the flow of data to the kernel.
It seems there are two places we queue cells into a cmux queue:
`circuitmux_append_destroy_cell()` and `append_cell_to_circuit_queue()`.
The latter triggers a "has waiting cells" for the scheduler which is what
we want but the former just bypasses it.
I think it should simply trigger that notify to the scheduler instead of
flushing it by itself.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/23712>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tor-bugs
mailing list