[tor-bugs] #23744 [Core Tor/Tor]: sched: Notification events have different meaning for each scheduler

[Tor Bug Tracker & Wiki]

#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