Search Linux Wireless

Re: [PATCH RFC v4 1/4] mac80211: Add TXQ scheduling API

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Wireless Personal Area Network]     [Linux Bluetooth]     [Wireless Regulations]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite Hiking]     [MIPS Linux]     [ARM Linux]     [Linux RAID]

  Powered by Linux