.. oh and I should add: * Review all the MORE bit uses with traffic in the PSQ and the software queue when leaking frames out via PS-POLL.
That's complicated as it has to check all TIDs for the existance of frames to TX, rather than a specific TID/AC. Adrian On 30 September 2012 22:39, Adrian Chadd <[email protected]> wrote: > 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 _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-wireless To unsubscribe, send any mail to "[email protected]"
