On 5/28/2018 1:36 PM, Johannes Berg wrote:
On Mon, 2018-05-28 at 12:49 +0530, Manikanta Pubbisetty wrote:
This doesn't seem right, all the logic that clears the TXQ_STOP etc.
still needs to be invoked, otherwise your TXQ will get stuck completely
since you'll never run this code again.
If the queues are blocked more than the block ack timeout then the
traffic should be sent only in the next BA session.
I am not really sure whether the queues will be blocked more than the
block ack timeout value unless the queues are stopped because of
multiple reasons.
In any case, traffic will be pushed out in subsequent BA sessions, no?
I'm not really sure what you're saying, but it sounds almost like you're
confusing a "BA session" with a single A-MPDU? The session will get
stuck if you do the code this way, I think.
Okay.
Also, you have the same problem as above - you never re-run this code so
you'd get stuck completely.
I didn't get your point here. By the time the queues gets started again,
there could be possibility that the station might have been back to
sleep. In this case, it is better not to send the traffic, no?
Anyways, station would receive the traffic in the next cycle when it is
out of sleep. Considering codel logic, there could be frame drops
though; maybe I am missing something?
But this is still the old code before cycling, so you never get here
during the TX cycle you're thinking of?
I did not understand your question fully ;-)
But then, as discussed earlier, it is best to mark the queues on which
driver attempted to dequeue and then release the packets once queues are
woken up.
Thanks,
Manikanta
