Received-SPF: pass (google.com: best guess record for domain of linux-wireless-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <20200313065114.23433-1-yhchuang@realtek.com> <87eetwo87q.fsf@kamboji.qca.qualcomm.com>
 <2e492e530d744713871f885e324106ef@realtek.com> <87eetrlanb.fsf@kamboji.qca.qualcomm.com>
 <ce990869ebf0478d98cd7e8416b36289@realtek.com> <875zf3kn05.fsf@kamboji.qca.qualcomm.com>
 <f4e7401c-c86b-8b2f-9e93-865322f71945@candelatech.com> <fbab3328d183406c923b30381389841f@realtek.com>
 <d45e2002e97c28acc1f9c7b9c41b5a3ba1d69452.camel@sipsolutions.net>
In-Reply-To: <d45e2002e97c28acc1f9c7b9c41b5a3ba1d69452.camel@sipsolutions.net>
From:   Brian Norris <briannorris@chromium.org>
Date:   Tue, 24 Mar 2020 17:03:46 -0700
Message-ID: <CA+ASDXM5tSmeE72+fn5K2vgR6kPE3OUbHJ_T_DVV63rFrPzv2w@mail.gmail.com>
Subject: Re: [PATCH] rtw88: add debugfs to fix tx rate
To:     Johannes Berg <johannes@sipsolutions.net>
Cc:     Tony Chuang <yhchuang@realtek.com>,
        Ben Greear <greearb@candelatech.com>,
        Kalle Valo <kvalo@codeaurora.org>,
        "linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-wireless-owner@vger.kernel.org
Precedence: bulk

[ To be clear, I haven't asked for this debugfs knob, and as of now,
there is no plan for Chrome OS to use $subject feature. Per some of
Tony's descriptions, I suppose maybe this would be useful for certain
debugging scenarios, but only that -- no intention of wiring this up
"in production." IIUC, he CC'd me only because of the "measuring the
TX power" portion of the commit message. ]

On Fri, Mar 20, 2020 at 6:06 AM Johannes Berg <johannes@sipsolutions.net> wrote:
> Brian can probably comment on this - I think ChromeOS (used to) use(s)
> some kind of fixed rate at the beginning of the connection to force low
> rates? But I also remember this interacting badly with some APs that
> just don't want to enable low rates at all...

Regarding how Chrome OS used NL80211_CMD_SET_TX_BITRATE_MASK: we used
to use this during authentication, association, DHCP, etc., until we
determined the connection was "established" -- the goal was to enforce
low (and ostensibly "more reliable") bitrates initially, so we get the
important stuff done, even in the presence of wacky rate control
algorithms. I understand this was actually added years ago mainly
because ath9k had poor rate control. Notably, this feature applies
(or, is supposed to apply) to both management and data frames.

As Johannes noted, masking off these rates caused problems of its own,
especially when APs (esp., guided by (mis?)guided I.T. admins who
think that low bitrates are evil) removed these low bitrates from
their SupportedRates field. Apparently these APs may start to reject
clients if they don't obey.

Additionally, we found no evidence that forcing low bitrates like this
was substantially helpful for anything other than older ath9k systems.
So longer story shorter, Chrome OS does not use
NL80211_CMD_SET_TX_BITRATE_MASK any more.

One is free to improve/extend the NL80211_CMD_SET_TX_BITRATE_MASK
command if desired, of course, but I think some of the earlier
complaints are valid (and line up with some of the problems I note
above): the use case for $subject does not necessarily involve setting
rates for management frames -- only data. One could always add extra
options to this command to reflect all the different ways this might
get used, but I'm not sure if that's worth it, for a feature that has
no non-debug use case.

One could also argue that, if iwlwifi already has a debugfs knob
(looks like rs_sta_dbgfs_scale_table_write()?), rtw88 should be able
to have one too ;)

Regards,
Brian