On 2019-03-18 23:14, Toke Høiland-Jørgensen wrote: > Felix Fietkau <nbd@xxxxxxxx> writes: > >> On 2019-03-17 22:59, Toke Høiland-Jørgensen wrote: >>> Felix Fietkau <nbd@xxxxxxxx> writes: >>>> I've looked at ath9k (the only user at the moment), and it seems to call >>>> the function in that way already: at PS wake or tx status time if it has >>>> frames in its internal retry queue. >>>> While it does not match the current documented behavior for that >>>> function, it nicely fits ath9k's currently unfulfilled expectations ;) >>> >>> Heh, fair point :) >> I noticed another issue: after the migration to the mac80211 txq >> scheduling code, ath9k does not handle stations going to powersave >> properly anymore. mac80211 keeps returning txqs for stations that have >> gone to sleep and ath9k will send out frames for them. > > Ah, right. Never did have a good grip on the powersave code... > >> We could deal with this in the driver and simply not return queues for >> stations in PS mode, or mac80211 could actively cancel them once a >> station enters PS mode. What do you prefer? > > I think the cleanest would be if mac80211 handled it and just > un-scheduled stations when they go to sleep. I agree. I'll send a patch tomorrow. > BTW, I was just thinking the other day about why the retry queue is kept > around when a station goes to sleep? Isn't the station usually sleeping > pretty long (>100 ms), where it might make more sense to drop things > rather than try again once i comes back? It doesn't always sleep long. It might just be background scanning. There's no way for the AP to know in advance. In any case, the A-MPDU receiver reorder window still needs to be maintained, so dropping frames means we'd have to send a BAR frame to notify the receiver, which costs airtime as well. - Felix
