.. 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.
On 30 September 2012 22:39, Adrian Chadd <adr...@freebsd.org> wrote:
> 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.)
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"