Re: [Make-wifi-fast] [PATCH RFC v4 1/4] mac80211: Add TXQ scheduling API

[Rajkumar Manoharan <rmanohar@codeaurora.org>]

On 2018-09-18 03:29, Toke Høiland-Jørgensen wrote:
> Rajkumar Manoharan <rmanohar@codeaurora.org> writes:
> 
>> 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.

>> 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.

>> 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