K 10
svn:author
V 6
adrian
K 8
svn:date
V 27
2011-08-06T04:49:25.126183Z
K 7
svn:log
V 1526
Now that aggregation and BAW tracking are in place, a whole lot of bad
assumptions (on my part, unfortunately) have crept up.

* Add some more debugging.
* Store away the original packet priority in ath_buf
* The TID is being incorrectly assigned. The TID should be 16 for
  non-QoS packets, regardless of what the priority is.
  The trouble is, the rest of the code assumes all packets in the
  given TID are destined for the same hardware txq - ie, they all
  have the same WME access class/priority value.

For example, if a packet has priority 0 (via M_WME_GETAC()) and
is a QoS enabled packet, it'll get a TID of 0. When aggregation
is enabled, these packets will also be tossed into the aggregation
state. Fine.

If a packet has priority 0 but isn't a QoS enabled packet, it'll also
get a TID of 0. This breaks things - non-QoS packets get thrown
into the aggregation state and suddenly everything is unhappy.

If I put non-QoS packets into TID 16, then I'm in the unhappy
situation that the packet priority may be non-zero (well, it may
be non-constant) and things suddenly crash.

This actually occurs in ieee80211_mgmt_output():

	ieee80211_send_setup(ni, m,
	     IEEE80211_FC0_TYPE_MGT | type, IEEE80211_NONQOS_TID,
	     vap->iv_myaddr, ni->ni_macaddr, ni->ni_bssid);
...
	M_WME_SETAC(m, params->ibp_pri);

So before I can continue, I likely need to correctly handle
TID=16 (non-QoS frames) which can have differing AC/PRI, and thus
different hardware TX queues. This influences what the locking
requirements are.

END