From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?utf-8?Q?Thomas_H=C3=BChn?= Date: Sun, 30 Nov 2014 12:30:44 +0100 Subject: [ath9k-devel] queue priority mapping In-Reply-To: References: <5472F604.3020404@fami-braun.de> <21621.50854.350744.269360@gargle.gargle.HOWL> Message-ID: <91ADAADD-6367-4C24-A965-9248A5D18D40@net.t-labs.tu-berlin.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: ath9k-devel@lists.ath9k.org Hi Hubert, >From my point of view the call-path of the functions look like this: ath9k_init_queues (struct ath_softc *sc ) -> ath_txq_setup (sc , ATH9K_TX_QUEUE_DATA, i ) with subtype-remapping via qi.tqi_subtype = subtype_txq_to_hwq [subtype]; -> 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 () defines and initializes the mapping with: static const int 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 /** 102 * enum ieee80211_ac_numbers - AC numbers as used in mac80211 103 * @IEEE80211_AC_VO: voice 104 * @IEEE80211_AC_VI: video 105 * @IEEE80211_AC_BE: best effort 106 * @IEEE80211_AC_BK: background 107 */ 108 enum ieee80211_ac_numbers { 109 IEEE80211_AC_VO = 0, 110 IEEE80211_AC_VI = 1, 111 IEEE80211_AC_BE = 2, 112 IEEE80211_AC_BK = 3, 113 }; 114 #define IEEE80211_NUM_ACS 4 from ath9k/hw.h: 218 enum ath_hw_txq_subtype { 219 ATH_TXQ_AC_BE = 0, 220 ATH_TXQ_AC_BK = 1, 221 ATH_TXQ_AC_VI = 2, 222 ATH_TXQ_AC_VO = 3, 223 }; this translates to the following mapping of AC to hw queues: static const int 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 : > > Hi Sujith, > > 2014-11-26 13:25 GMT+01:00 Sujith Manoharan >: >> 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[] 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 > 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