> 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. Now, let me explain how I'd implement this: The driver is first changed to always keep track of the frame cookie/ID for the last frame inserted into each queue. This needs a single u32 per hardware queue. Then, when insert_queue_barrier() is called, the driver saves the following information in a list: * sta mac addr * cookie * last frame cookie for all possible queues On TX status/completion notification, the driver checks for the first barrier in the list whether all frame cookies have been completed. This can either be implemented by making the cookies be increasing numbers or walking the barrier list for each completed cookie and clearing those that have been processed. When a barrier has been processed completely, it calls the ieee80211_barrier_completed() function and removes it from the list. johannes
Attachment:
signature.asc
Description: This is a digitally signed message part
