Hi, I'm about to start tinkering with ath(4) power save support and I'd like to introduce some net80211 changes to support this.
* Methodize the STA and node power save functions, so the driver can stop/start the software queues as needed; * Push PS-POLL frame leaking into a method, so the driver can override this if something is in a local queue. Since the driver may have some software queued frames for it, the driver needs to be able to leak these frames out correctly before the power-save queue frames are transmitted. My initial change to ath(4) will be to pause and unpause the node when the net80211 stack calls iv_node_ps() so the driver doesn't bother transmitting to a node that's asleep. There's a bunch of other needed changes that I'll then do in some follow-up work: * The TIM/ATIM doesn't know about what's in the software queue, so I'm going to have to introduce some further methods to allow the driver to update the TIM/ATIM as needed; * There's a M_PWR_SAV mbuf flag that means "this came from the power save queue". I need to see what/how drivers should treat this; * When a frame is sent via the PS-POLL method whilst a STA is asleep, the TIDs may be paused and as such the node won't transmit. In this case, frames pushed from the power save queue to the driver should immediately be transmitted, rather than punted to the software queue. * I also need to verify that the CABQ traffic is being set correctly- ie, the CABQ traffic all has the MORE bit appropriately set or cleared. * For nodes that are being sent PS-POLL (and later, uAPSD) delivered frames, they should be put "next" on the TX queue, ahead of any other TIDs that are being scheduled. That way their frame goes out next (or has a good chance to), versus being behind all the other currently transmitting (but not in power save) nodes. This should allow the device to quickly receive the frame and go back to sleep. I'm going to leave the next set of changes until I've done the first bit of work and verified it's working. I'll likely make that behaviour configurable because I'm worried that the incomplete PS-POLL upgrades will break mobile devices that try to stay in PS-POLL and "leak" frames (versus things like my MBP that just go in/out of power save and don't use PS-POLL at all.) adrian
Description: Binary data
_______________________________________________ email@example.com mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"