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
* 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.)


Attachment: 2012-09-30-powersave.diff
Description: Binary data

freebsd-wireless@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

Reply via email to