On 2019-09-18 05:31, Toke Høiland-Jørgensen wrote:
Yibo Zhao <yiboz@xxxxxxxxxxxxxx> writes:
From: Toke Høiland-Jørgensen <toke@xxxxxxxxxx>
This switches the airtime scheduler in mac80211 to use a virtual
time-based
scheduler instead of the round-robin scheduler used before. This has a
couple of advantages:
- No need to sync up the round-robin scheduler in firmware/hardware
with
the round-robin airtime scheduler.
- If several stations are eligible for transmission we can schedule
both of
them; no need to hard-block the scheduling rotation until the head
of the
queue has used up its quantum.
- The check of whether a station is eligible for transmission becomes
simpler (in ieee80211_txq_may_transmit()).
The drawback is that scheduling becomes slightly more expensive, as we
need
to maintain an rbtree of TXQs sorted by virtual time. This means that
ieee80211_register_airtime() becomes O(logN) in the number of
currently
scheduled TXQs. However, hopefully this number rarely grows too big
(it's
only TXQs currently backlogged, not all associated stations), so it
shouldn't be too big of an issue.
Signed-off-by: Toke Høiland-Jørgensen <toke@xxxxxxxxxx>
I'll note that this patch still has the two issues that Felix pointed
out when I posted the RFC version. Namely:
- The use of divisions in the fast path. I guess I need to go write
some
reciprocal-calculation code, since that is also an issue with the AQL
patches I linked to before.
- The fact that we don't count the airtime usage of multicast traffic,
which with this series means that the vif TXQ will get priority over
the others. I think we agreed to fix this by just adding an airtime
v_t to the vif as well and use that for scheduling the TXQ. Does
ath10k report airtime usage for multicast as well, or only for
stations?
I remember we have Felix' patches reducing the time the lock is held in
mac80211 for DRR, do we need to integrate it into this version？
-Toke
--
Yibo
