On 2019-09-23 18:47, Toke Høiland-Jørgensen wrote:
Yibo Zhao <yiboz@xxxxxxxxxxxxxx> 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
