MIME-Version: 1.0
References: <20211125121652.6073-1-jelonek.jonas@gmail.com> <878rxcb4q2.fsf@toke.dk>
In-Reply-To: <878rxcb4q2.fsf@toke.dk>
From:   Jonas Jelonek <jelonek.jonas@gmail.com>
Date:   Thu, 25 Nov 2021 23:38:52 +0100
Message-ID: <CAChE-vT1UMw2iadzuzsUPEcAopi=86N4GV_b4=chZbSvap3x=A@mail.gmail.com>
Subject: Re: [PATCH] ath9k: switch to rate table based lookup
To:     =?UTF-8?B?VG9rZSBIw7hpbGFuZC1Kw7hyZ2Vuc2Vu?= <toke@redhat.com>
Cc:     linux-wireless@vger.kernel.org, kvalo@codeaurora.org, nbd@nbd.name,
        Thomas Huehn <thomas.huehn@hs-nordhausen.de>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

> 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.