> What's the practical implication of this? Performance benefits, better > rates selected, or what? Got any benchmark numbers? We're planning to annotate and implement 'transmit power control' per packet / per MRR and to improve the rate control API in mac80211 to support newer hardware. SKB->CB is limited in space, tx power annotation also does not fit in there. Future perspective is that rate control won't use SKB->CB anymore, neither for normal rate setting nor for probing. The new rate control API (introduced with commit 0d528d85c519b755b6f4e1bafa3a39984370e1c1) allows drivers to directly get rates from sta->rates. This is not used by every driver yet, ieee80211_get_tx_rates performs the translation/merge for the drivers. The call to ieee80211_get_tx_rates and subsequent calls in ath9k can be avoided by directly fetching rates from sta->rates. This may also improve performance. ath9k does not expect rates in SKB->CB, therefore table merge does not need to consider this (except for first rate in SKB->CB for probing). > You don't generally need a co-developed-by for yourself, and your S-o-b > should go at the end when you're the submitter... will fix this in V2.
