[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[tor-bugs] #23744 [Core Tor/Tor]: sched: Notification events have different meaning for each scheduler
#23744: sched: Notification events have different meaning for each scheduler
------------------------------+--------------------------------
Reporter: dgoulet | Owner: (none)
Type: defect | Status: new
Priority: High | Milestone: Tor: 0.3.3.x-final
Component: Core Tor/Tor | Version:
Severity: Normal | Keywords: tor-sched
Actual Points: | Parent ID:
Points: | Reviewer:
Sponsor: |
------------------------------+--------------------------------
As an example, KIST controls how much and when channel data is pushed on
the network which means this `wants to write` event used by the Vanilla
scheduler as "queued cell but no space on the outbuf" is not something
that is coherent with KIST.
A channel is scheduled in when it has cells in the queue, then they are
flushed one by one by the KIST scheduler until the kernel says "no more
space". Then, that channel is put back in the channel pending list and
will get handled at the next tick of KIST.
So, we really don't need KIST to be notified of this event from
`connection_flushed_some()` which is used by Vanilla to try to flush more
cells in the outbuf because the outbuf has room for it.
Where it is useful is the second callsite of that even in
`channel_tls_handle_state_change_on_orconn()` which notifies the scheduler
that it might be in need of flushing some stuff. In the case of a brand
new channel just opening, its state is "IDLE" and that even will then put
it in "waiting for cells" after.
That being said, what needs to happened:
1. Make the notification event a per-scheduler thing because KIST and
Vanilla have different semantic for those events really. We should of
course avoid as much as we can of code duplication and thus some "generic
event handler" do make sense if they share the same semantic.
2. Add a "channel state is open" notification event instead of "wants to
write" which is really only true in very specific cases in
`channel_tls_handle_state_change_on_orconn()`. That way, the scheduler can
take a decision on the status of the channel instead of blind guessing it
is waiting for cells.
3. Nullify the "wants to write" event for KIST considering (2) so it stops
possibly scheduling channels that do not need at all to be scheduled.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/23744>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs