> Hey, and there is also ipw firmware! Yeah but I know nothing about it and you haven't published anything yet :) > As broadcom, the iwl4965AGN firmware is also aware of the powersave > state for the station/stations (consider about the master mode). In > stead of having a special "power management queue", "Power management queue" is a bit misleading, it's not a frame queue, it's a queue/fifo of power management status notifications. > the 4965 firmware > still use the normal 4 QoS queues for frames destined to powersaved > STAs. Yes, same for Broadcom. > But these frames will be dropped by firmware eventually. Yeah, they're suppressed by firmware if the STA has gone to sleep between the frame being queued by the driver and processed by the firmware. > In this > case, mac80211 ieee80211_tx_status() will get these SKBs with a tx error > state DST_STA_IN_POWERSAVE so that it can requeue them (to send them > later when STA wakes up). You should indicate that to mac80211 by using the TX_FILTERED TX status flag. > Note, this scheme is to resolve the race > condition you mentioned that in the small window the STA powersave state > mismatches between mac80211 and firmware. After mac80211 receives the PS > frame, it stops to Tx more frames to hardware. Right. This completely solves the race, there's a possible scheme where the host notifies the firmware of powersave status changes which will still help because this can be made faster than the TX queues, but still leaves a small window. That was hypothetical though, I guess nobody implements such a scheme. > This scheme works well but we have one requirement for mac80211. That > is, in the master mode, when the destined STA wakes up from powersave > mode, mac80211 should not begin to Tx frames to hardware until the > current h/w Tx queues are drained. Otherwise we can expect frames out of > order issue happens (for example, some frames in h/w queues are requeued > but others are left when mac80211 begins to Tx). Good point. Completely draining isn't really possible when we're communicating with another station nor is it necessary, inserting a sort of "barrier" into the queue (any frame would be sufficient) would be good enough so that you know when all frames inserted before the powersave status change are drained. On the other hand, even that is not necessary. Because we stop TX to a STA right away once we see a STA going to sleep it would be sufficient to insert a barrier into all queues when the STA goes to sleep and later wait for those barriers to complete, which in most cases they will already have. [continuing below] > It's good that you look into mac80211 powersave now. We also have code > that enables master mode PS poll and uAPSD based on an early version of > mac80211. We will merge it to the latest mac80211 and submit but it > takes some time. I can point you the patch if you are interested. I'm somewhat interested, I was trying to get my N810 to perform well with a Broadcom/mac80211 based AP. I'd be much more interested in having an iwl4965 ucode image and driver patches to get master mode working there though :) As for implementing the "barrier" scheme, the following could work: When a STA goes to sleep, mac80211 calls a new ops->insert_queue_barrier(hw, u8 *sta, u32 cookie) callback in the driver. This callback takes note of all current queue status and inserts the status information into a list. mac80211 has created a cookie (probably just based on an increasing per-sta counter) and saves that cookie in the sta_info for that particular sta (this barrier cookie is to allow having two barriers for the same STA in flight at the same time). As part of TX status processing, the driver now checks whether any of the barriers completed by comparing the TX queue status to the list of barriers. It then calls a new void ieee80211_barrier_completed(u8 *sta, u32 cookie) mac80211 function. mac80211 looks up the sta and clears the cookie if it matches, and if so also schedules all outstanding frames for transmission. Additionally, mac80211 is changed to not transmit if the sta has a barrier cookie assigned. What do you think? johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
