From:   Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= <toke@redhat.com>
To:     Kalle Valo <kvalo@codeaurora.org>,
        Jonas Jelonek <jelonek.jonas@gmail.com>
Cc:     "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>,
        "nbd@nbd.name" <nbd@nbd.name>,
        Thomas Huehn <thomas.huehn@hs-nordhausen.de>
Subject: Re: [PATCH] ath9k: switch to rate table based lookup
In-Reply-To: <878rxb3qus.fsf@codeaurora.org>
References: <20211125121652.6073-1-jelonek.jonas@gmail.com>
 <878rxcb4q2.fsf@toke.dk> <87a6hrwg1f.fsf@tynnyri.adurom.net>
 <CAChE-vTktHRW1JR8s1NNnLOqfBihd=5T2qXDsQDyBeecw95U0g@mail.gmail.com>
 <878rxb3qus.fsf@codeaurora.org>
Date:   Fri, 26 Nov 2021 19:33:39 +0100
Message-ID: <87lf1aahrw.fsf@toke.dk>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

Kalle Valo <kvalo@codeaurora.org> writes:

> Jonas Jelonek <jelonek.jonas@gmail.com> writes:
>
>>> And how did you test this? Are both PCI and USB devices affected?
>>
>> I tested this on a 8devices Rambutan with QCA9558 SoC, but didn=E2=80=98t
>> explicitly test this with a USB device. I am not sure whether the
>> ath9k_htc is affected. First I tested this without the patch to get a
>> reference for comparison. I connected three devices via WiFi 2.4GHz
>> and 5GHz, generated traffic multiple times with iperf3 and captured
>> the rc_stats for each station. Then I applied the patch and did the
>> same again. The throughput was overall the same like without the
>> patch, compared to the first run of each station. Rate selection
>> worked fine, the stats were nearly identical, same rates selected in
>> both runs.
>
> Thanks. Can someone review this from ath9k_htc point of view?

Pretty sure ath9k_htc devices do rate control in the firmware. Certainly
ath9k_htc sets the HAS_RATE_CONTROL flag in mac80211, and the only calls
to ath_set_rates are from within xmit.c, which is not used by ath9k_htc.
So I think we're fine as far as that is concerned...

-Toke