Now that I'm "done" with TX aggregation, now we need to figure out
adrian at freebsd.org
Sat Apr 7 20:27:39 UTC 2012
Now that I've "finished" with the TX aggregation side of ath(4), I'd
like to go and make power save support work (again).
* the hacky logic I put into the ath(4) TX queue code is wrong and
seems to cause lots of weird issues when a power save station comes
along whilst some other 11n aggregation stuff is happening;
* since the ath(4) driver now has a per-TID, per-node queue of frames,
ps-poll and TIM updating just don't work as you'd expect.
If a power save client wakes up and sends a ps-poll frame to the
hostap right now, the only software queue net80211 has is the power
save queue (psq) which frames are diverted to if they're queued whilst
the station is in power save mode. However, this doesn't take into
account frames in the software queue, nor does it try at all to deal
with frames that were already in flight. In the legacy case that's
"ok" as those frames would be dropped with no real state consequence
(there'd be a hole in the sequence numbers, but that's ok for legacy
operation.) But in 11n, we can't just drop frames in the TX queue.
The other issue is that if there -are- frames in the software queue,
those should be dequeued (as aggregates? I'm not sure) before frames
on the net80211 psq should be dequeued. Similarly, the TIM needs to be
updated with the state of the psq _and_ the per-TID, per-node software
On the other hand, the hardware gives us a few things to make this easier.
If TX failures occur, the hardware (Dating back to the pre-11n NICs)
will set a "destination filtered" bit somewhere; which prevents all
further hardware queued frames from even being attempted. They'll
immediately fail with a specific error. So for stations transitioning
into power save mode, we won't waste air time trying to transmit
frames when it just plain isn't working. Those frames can then be
added to the beginning of the software queue and retried once the
station comes out of power save mode.
Right now all frames have the "clear destination mask bit" set in the
TX descriptor. I can clear that bit, notice when frames fail, throw
them back on the head of the software queue and retry them when the
station comes back. We just tag the next frame with the "clear
destination mask bit" in the TX descriptor so traffic starts again.
So, in short - this is a bit of a mess to wade through. I'd appreciate
some feedback/comments. My plan is to ignore this for the next couple
of weeks and concentrate on bugfixing anything that leads to crashes,
memory corruption and such. There's also a lot of codebase tidying up
that I'd like to do, especially with the messy locking. But handling
power save needs to be done..
More information about the freebsd-wireless