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. > > 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? johannes
