Direct-dispatching addba frames and to the correct hardware queue?
adrian at freebsd.org
Fri Jun 17 11:27:40 UTC 2011
I've found that all the HT action frames are assigned to the WME
priority 3 (voice). This means they'll go out in a different hardware
queue in ath(4) than any pre-aggregation frames queued to the
So the ADDBA frame appears before some of the already-queued frames.
Frames in the ath software TX queue can be held, but those in the
hardware queue can't.
I've added a hack to my branch that rewrites the priority on ADDBA
frames, and also marks them as direct dispatch to the hardware rather
than stuffed in the software queue. But I'd rather this be done in the
So the questions!
* Should the stack be throwing the action frame(s) for a given TID
onto the right hardware queue?
* Should there be an ieee80211_param flag that says "don't software
queue, please just send straight through thanks?" for things like
action frames that should behave as above?
* Should the ADDBA (and DELBA) TX be split out from the actual status
change so the driver can actually say when the frames go out? Ie, the
driver can wait for all pending packets to the given node in the
relevant TID to have gone out before completing the ADDBA transaction.
I'm not sure yet about DELBA as I haven't yet gotten to implementing
I don't mind leaving this dirtiness in the ath(4) code I'm working on
for now until we've figured out a cleaner option, so there's no rush
to figure it out.
More information about the freebsd-wireless