[Make-wifi-fast] [PATCH RFC v5 3/4] mac80211: Add airtime accounting and scheduling to TXQs
Rajkumar Manoharan
rmanohar at codeaurora.org
Wed Oct 10 00:52:37 EDT 2018
On 2018-10-09 05:32, Toke Høiland-Jørgensen wrote:
> This adds airtime accounting and scheduling to the mac80211 TXQ
> scheduler. A new callback, ieee80211_sta_register_airtime(), is added
> that drivers can call to report airtime usage for stations.
>
> When airtime information is present, mac80211 will schedule TXQs
> (through ieee80211_next_txq()) in a way that enforces airtime fairness
> between active stations. This scheduling works the same way as the
> ath9k
> in-driver airtime fairness scheduling. If no airtime usage is reported
> by the driver, the scheduler will default to round-robin scheduling.
>
> For drivers that don't control TXQ scheduling in software, a new API
> function, ieee80211_txq_may_transmit(), is added which the driver can
> use
> to check if the TXQ is eligible for transmission, or should be
> throttled to
> enforce fairness. Calls to this function must also be enclosed in
> ieee80211_txq_schedule_{start,end}() calls to ensure proper locking.
> TXQs
> that are throttled by ieee802111_txq_may_transmit() will be woken up
> again
> by a check added to the ieee80211_wake_txqs() tasklet.
>
Toke,
I am observing soft lockup issues again with this new series while
running
traffic with 50 clients. I am continuing testing with earlier series
along with
snippet I shared. When driver operates in pull-mode, throttled txqs are
marked
and refilled in airtime_tasklet. This is causing major throughput drops
and
packet loss and I am suspecting the latency in replenishing deficit.
Whereas in push-mode or in ath9k model, refill happens quicker at every
packet
indication as well as tx completion.
I am planning to get rid of tasklet completely as it is only meant for
pull-mode.
It would be better to refill in may_transmit() itself.
-Rajkumar
More information about the Make-wifi-fast
mailing list