Date: Sun, 30 Sep 2012 22:43:12 -0700 From: Adrian Chadd <adrian@freebsd.org> To: freebsd-wireless@freebsd.org Subject: Re: [RFC] Methodize the net8021 power save hooks Message-ID: <CAJ-VmomoHmZcj=NY_Y=CcX=qnsfaYqWEMVNEp_rx%2BH94jbWSeA@mail.gmail.com> In-Reply-To: <CAJ-VmonvY1RyoruDeDL7NNXDgv-=iOEZ7S_teUu67iiAQ661Nw@mail.gmail.com> References: <CAJ-VmonvY1RyoruDeDL7NNXDgv-=iOEZ7S_teUu67iiAQ661Nw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
.. 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 <adrian@freebsd.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-VmomoHmZcj=NY_Y=CcX=qnsfaYqWEMVNEp_rx%2BH94jbWSeA>