Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 6 Nov 2012 10:31:26 -0800
From:      Adrian Chadd <adrian@freebsd.org>
To:        freebsd-wireless@freebsd.org
Subject:   Update: TX aggregation code changes in preparation for AR9380 support; PS-POLL is really broken
Message-ID:  <CAJ-Vmokd2hC9GcS2-CKLS1zm=Ds-OAqHwqD-e7a_sizA-PJRLA@mail.gmail.com>

next in thread | raw e-mail | index | archive | help
Hi all,

Here's the update!

I've rearchitected how the TX descriptor setup code runs so 802.11n
aggregation setup re-uses much of the same code as non-aggregation.
This allowed me to enable TX aggregation for my AR9380 NIC. I've only
tested it to 2 streams (as I don't have a 3 stream AP at home :-) It's
possible this has had some unintended side-effects for the existing
11n and non-11n chips so if you can test, please do.

My power save code works great RIGHT until you use ps-poll. Then
things go completely whacked. Simply - I now correctly update the TIM
and pause the software TX queue for a given station if it goes into
power save mode. But when a PS-POLL is received, there's no way to
send anything back to the node.

I now need to finish my power save work so PS-POLL can leak frames
from the driver first, THEN leak frames from the net80211 psq. It's a
bit tricky as the net80211 psq frames are queued before they're
encapsulated. So when the stack leaks out PS-POLL frames, it sends
them to the driver with M_PWR_SAV set in the mbuf. The driver then
needs to ensure those frames get handled correctly. Ie:

* if there's anything in the software queue, leak those out one at a
time (obeying all of the 802.11n aggregation checks and block-ack
window stuff);
* If the software queue is empty, allow net80211 to schedule traffic
to that node from the psq (which will send the frame through the
net80211 stack to be encapsulated), then again make sure that only
-one- frame gets sent out.

I don't think it's going to be that difficult. I just have to teach
the software queue handling to:

* Have some concept of a "leak exactly one frame out, then clear this
flag" ps-poll flag for each node;
* When a node gets scheduled, check if the ps-poll node flag is set
and if so, schedule it at high priority (ie, in a "ps-poll" software
queue, rather than putting the node on the normal software queue);
* When doing the software dispatch run, only leak one node out at a
time, rather than "send all the frames until the hardware queue is
busy".

So for now, as this is going to take a tad longer than I thought, I'll
push in a change to disable my power save work so the TIM and software
TX pausing/unpausing doesn't get updated. I'll enable it locally for
development, but it'll disable to the older behaviour of "just keep
sending stuff to the STA." That will at least unbreak ps-poll devices.

Thanks to Garrett Cooper for sending me a HP Touchpad - primarily so I
have a reference ARM+ath6kl wireless platform, but also because it
turns out that _it_ does aggressive ps-poll handling. I can now figure
out how to correctly behave here. :-)



Adrian



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-Vmokd2hC9GcS2-CKLS1zm=Ds-OAqHwqD-e7a_sizA-PJRLA>