Re: [PATCH RFC v4 1/4] mac80211: Add TXQ scheduling API
From: Rajkumar Manoharan <hidden>
Date: 2018-09-19 00:25:39
On 2018-09-18 03:29, Toke Høiland-Jørgensen wrote:
Rajkumar Manoharan [off-list ref] writes:quoted
On 2018-09-16 10:42, Toke Høiland-Jørgensen wrote: return_txq() should return a bool to inform the driver that whether txq is queued back or not.What would the driver do with that return value, exactly?
never mind.. got lost with earlier schedule_txq API.
quoted
Otherwise the same txq will be served indefinitely until txq becomes empty. This problem occurs when the driver is running out of hw descriptors or driver sends only N frames (< backlog_packets).No, if it's using next_txq(), the API guarantees that the same TXQ will not be returned more than once between a set of calls to schedule_start()/schedule_end() (by way of the seqno mechanism). I didn't add the same check to may_transmit(), because I assumed the driver would not be looping in this case. Is that not correct?
Yeah.. you are correct. sorry for the noise.
quoted
Also an option to add the node at head or tail would be preferred. If return_txq adds node at head of list, then it is forcing the driver to serve same txq until it becomes empty. Also this will not allow the driver to send N frames from each txqs.The whole point of this patch set is to move those kinds of decisions out of the driver and into mac80211. The airtime scheduler won't achieve fairness if it allows queues to be queued to the end of the rotation before its deficit turns negative. And obviously there's some lag in this since we're using after-the-fact airtime information.
Hmm.. As you know ath10k kind of doing fairness by serving fixed frames from each txq. This approach will be removed from ath10k.
For ath9k this has not really been a problem in my tests; if the lag turns out to be too great for ath10k (which I suppose is a possibility since we don't get airtime information on every TX-compl), I figure we can use the same estimated airtime value that is used for throttling the queues to adjust the deficit immediately...
Thats true. I am porting Kan's changes of airtime estimation for each msdu for firmware that does not report airtime. -Rajkumar