[ath9k-devel] queue priority mapping

["Thomas Hühn" <thomas@net.t-labs.tu-berlin.de>]

Hi Hubert,

From my point of view the call-path of the functions look like this:

ath9k_init_queues <http://lxr.free-electrons.com/ident?i=ath9k_init_queues>(struct ath_softc <http://lxr.free-electrons.com/ident?i=ath_softc> *sc <http://lxr.free-electrons.com/ident?i=sc>) 
       -> ath_txq_setup <http://lxr.free-electrons.com/ident?i=ath_txq_setup>(sc <http://lxr.free-electrons.com/ident?i=sc>, ATH9K_TX_QUEUE_DATA, i <http://lxr.free-electrons.com/ident?i=i>) with subtype-remapping via 
		qi.tqi_subtype = subtype_txq_to_hwq <http://lxr.free-electrons.com/ident?i=subtype_txq_to_hwq>[subtype];
			-> ath9k_hw_setuptxqueue <http://lxr.free-electrons.com/ident?i=ath9k_hw_setuptxqueue>(ah, qtype, &qi);

And the subtyperemapping reflects the correct AC class mapping to ath9k hw queues.
In xmit.c function ath_txq_setup <http://lxr.free-electrons.com/ident?i=ath_txq_setup>() defines and initializes the mapping with:

static const int subtype_txq_to_hwq <http://lxr.free-electrons.com/ident?i=subtype_txq_to_hwq>[] = {
	[IEEE80211_AC_BE] = ATH_TXQ_AC_BE,
	[IEEE80211_AC_BK] = ATH_TXQ_AC_BK,
	[IEEE80211_AC_VI] = ATH_TXQ_AC_VI,
	[IEEE80211_AC_VO] = ATH_TXQ_AC_VO,
};
from mac80211.h:
101 <http://lxr.free-electrons.com/source/include/net/mac80211.h#L101> /**
102 <http://lxr.free-electrons.com/source/include/net/mac80211.h#L102>  * enum ieee80211_ac_numbers - AC numbers as used in mac80211
103 <http://lxr.free-electrons.com/source/include/net/mac80211.h#L103>  * @IEEE80211_AC_VO: voice
104 <http://lxr.free-electrons.com/source/include/net/mac80211.h#L104>  * @IEEE80211_AC_VI: video
105 <http://lxr.free-electrons.com/source/include/net/mac80211.h#L105>  * @IEEE80211_AC_BE: best effort
106 <http://lxr.free-electrons.com/source/include/net/mac80211.h#L106>  * @IEEE80211_AC_BK: background
107 <http://lxr.free-electrons.com/source/include/net/mac80211.h#L107>  */
108 <http://lxr.free-electrons.com/source/include/net/mac80211.h#L108> enum ieee80211_ac_numbers <http://lxr.free-electrons.com/ident?i=ieee80211_ac_numbers> {
109 <http://lxr.free-electrons.com/source/include/net/mac80211.h#L109>         IEEE80211_AC_VO         = 0,
110 <http://lxr.free-electrons.com/source/include/net/mac80211.h#L110>         IEEE80211_AC_VI         = 1,
111 <http://lxr.free-electrons.com/source/include/net/mac80211.h#L111>         IEEE80211_AC_BE         = 2,
112 <http://lxr.free-electrons.com/source/include/net/mac80211.h#L112>         IEEE80211_AC_BK         = 3,
113 <http://lxr.free-electrons.com/source/include/net/mac80211.h#L113> };
114 <http://lxr.free-electrons.com/source/include/net/mac80211.h#L114> #define IEEE80211_NUM_ACS <http://lxr.free-electrons.com/ident?i=IEEE80211_NUM_ACS>       4
from ath9k/hw.h:
218 <http://lxr.free-electrons.com/source/drivers/net/wireless/ath/ath9k/hw.h#L218> enum ath_hw_txq_subtype <http://lxr.free-electrons.com/ident?i=ath_hw_txq_subtype> {
219 <http://lxr.free-electrons.com/source/drivers/net/wireless/ath/ath9k/hw.h#L219>         ATH_TXQ_AC_BE = 0,
220 <http://lxr.free-electrons.com/source/drivers/net/wireless/ath/ath9k/hw.h#L220>         ATH_TXQ_AC_BK = 1,
221 <http://lxr.free-electrons.com/source/drivers/net/wireless/ath/ath9k/hw.h#L221>         ATH_TXQ_AC_VI = 2,
222 <http://lxr.free-electrons.com/source/drivers/net/wireless/ath/ath9k/hw.h#L222>         ATH_TXQ_AC_VO = 3,
223 <http://lxr.free-electrons.com/source/drivers/net/wireless/ath/ath9k/hw.h#L223> };
this translates to the following mapping of AC to hw queues:
static const int subtype_txq_to_hwq <http://lxr.free-electrons.com/ident?i=subtype_txq_to_hwq>[] = {
	[2] = 0,
	[3] = 1,
	[1] = 2,
	[0] = 3,
};

That is how I understand the source code and yes it looks a bit complicated but function wise seems to be correct.
Or do I miss something here ?

Greetings from Berlin
Thomas




> Am 27.11.2014 um 13:04 schrieb Hubert Feurstein <h.feurstein@gmail.com>:
> 
> Hi Sujith,
> 
> 2014-11-26 13:25 GMT+01:00 Sujith Manoharan <sujith at msujith.org <mailto:sujith@msujith.org>>:
>> Hubert Feurstein wrote:
>>> Well, in fact it does. To understand my post you have to know the
>>> behaviour of ath_txq_setup. The point here is that on the first call
>>> of ath_txq_setup(..ATH9K_TX_QUEUE_DATA..), hw-queue 0 is returned. On
>>> the second call hw-queue 1 is returned, ... . And IEEE80211_AC_VO = 0,
>>> so hw-queue 0 is assigned, which is wrong in my opinion. But the right
>>> place to fix this would be ath_txq_setup itself.
>> 
>> The mapping has been changed recently and I think it might be a problem,
>> since this is what the datasheet says:
>> 
>> "The mapping of physical DCUs to absolute channel access priorities is fixed and
>> cannot be altered by software."
> 
> Yes I know, and isn't this the reason why there is
> sc->tx.txq_map[<AC>] in place, to map the AC to the proper HW queue in
> software. So sc->tx.txq_map[IEEE80211_AC_VO] should return the
> higher-prio-queue 3 and not the low-prio-queue 0. In FreeBSD it is
> that way, in Linux it is the opposite, because in Linux
> IEEE80211_AC_VO=0 and in FreeBSD WME_AC_VO=3.
> 
> Hubert
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org <mailto:ath9k-devel@lists.ath9k.org>
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel <https://lists.ath9k.org/mailman/listinfo/ath9k-devel>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20141130/aa6eeb3b/attachment.htm