Re: [RFC 3/3] mac80211: add ieee80211_reorder_txq

[Rajkumar Manoharan <rmanohar@codeaurora.org>]

On 2018-08-22 04:10, Toke Høiland-Jørgensen wrote:
> Rajkumar Manoharan <rmanohar@codeaurora.org> writes:
> 
>> On 2018-08-21 05:24, Toke Høiland-Jørgensen wrote:
>>> Rajkumar Manoharan <rmanohar@codeaurora.org> writes:
>>> 
[...]

> Yeah, but the fairness comes from all TXQs being given the *same 
> amount*
> of deficit increase. I.e., with reorder_txq() there needs to be a
> guarantee that it is called the same number of times for all active
> TXQs. Which is what the round-robin scheduling ensures in next_txq().
> 
Understood.

>> As mentioned earlier, next_txq() can not be used for fetching txq
>> directly. So reorder_txq() needs to take care of refilling txq after
>> serving them.
> 
> Yeah, I got that; but see above. Unless there's a guarantee that the
> push/pull mechanism will be round-robin scheduled (which as I'm reading
> the code there isn't), just increasing the deficit on every call to
> reorder_txq() is not going to ensure fairness (it'll probably help 
> some,
> but it won't be completely fair).
> 
> However, if we add the check to reorder_txq() so the deficit increase +
> rotation is only done if the TXQ is at the head of the list, we'll get
> round-robin-equivalent behaviour since a TXQ will only get to continue
> when it happens to have rotated to the head of the queue. As I 
> mentioned
> previously it will break MIMO, but I we could fix that later once we've
> verified that the basic mechanism works.
> 
Hmm... The pull mechanism operates in round-robin fashion. Agree that
accessing only head node is right way of ensuring fairness. Will fix it
and rename as ieee80211_txq_can_transmit().

Thanks Toke for your feedback.

-Rajkumar