Felix Fietkau <nbd@xxxxxxxx> writes: > 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. Cool, thanks! :) >> 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. Right, makes sense; thanks for the explanation. -Toke
