Jonas Jelonek <jelonek.jonas@xxxxxxxxx> writes: >> 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. Ah, great! > 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). Please put something like the above explanation in the commit message so people can understand the context. And as Kalle pointed out, some information on how you tested this is also needed, and can go into the commit message as well :) -Toke
