Re: [PATCH 2/4] mac80211: defer txqs removal from rbtree

[Yibo Zhao <yiboz@codeaurora.org>]

On 2019-09-23 18:47, Toke Høiland-Jørgensen wrote:
> Yibo Zhao <yiboz@codeaurora.org> writes:
>>> So, instead we need to keep next_txq() the way it is, and just add
>> 
>> Right, should keep next_txq() the way it is.
>> 
>>> 
>>> local->schedule_pos[ac] = rb_prev(node);
>>> 
>>> whenever we remove a node (both in return_txq() and resort_txq()).
>> 
>> Agree, and also we may need to consider case like A is removed and 
>> soon
>> be added back just the same as ii),
>>         B->C->A->D->E
>> then B is schedule, removed and soon added back,
>>         C->A->B->D->E
>> A and B will have a second chance to be scheduled and this may happen 
>> to
>> others as well leading to the infinite loop as you have mentioned
>> previously, so do we need to maintain a schedule_round like we do in
>> DRR? Like,
>>      - If the node is in the same round, by pass schedule, go to
>> rb_next(), either continue loop this round or end this round.
>>      - Increase the schedule_round at the schedule_start() only when 
>> the
>> schedule_pos is NULL.
> 
> Hmm, yeah, I guess we could end up with a loop like that as well.
> Keeping the schedule_round would be a way to fix it, but I'm not sure 
> we
> should just skip that station; maybe we should just end the round
> instead?
I am not sure. I believe, in some cases, the rest of the nodes which 
could be most of the nodes in the tree will not have the chance to be 
scheduled in this round.

> 
>>>>> We'd still need a check in resort_txq() then, but it would make it
>>>>> safe
>>>>> to unschedule in return_txq()...
>>>> Yes, agree with that.
>>>> 



-- 
Yibo