Content-Type: text/plain;
        charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.400.51.1.1\))
Subject: Re: [RFC v2 5/6] mac80211_hwsim: add TPC per packet support
From:   Jonas Jelonek <jelonek.jonas@gmail.com>
In-Reply-To: <386f10e09c17b871df1c86ebc0c2af52938c6fb6.camel@sipsolutions.net>
Date:   Fri, 3 Mar 2023 08:42:06 +0100
Cc:     linux-wireless@vger.kernel.org, Felix Fietkau <nbd@nbd.name>
Content-Transfer-Encoding: quoted-printable
Message-Id: <08F35885-A18C-49C5-B5F5-9FC8F4BBD401@gmail.com>
References: <20220920104032.496697-1-jelonek.jonas@gmail.com>
 <20220920104032.496697-6-jelonek.jonas@gmail.com>
 <5d15d193c76dcc2cbd59b26912973e3bce34c776.camel@sipsolutions.net>
 <951FA42C-E52F-4FDB-AB73-AEF76435380C@gmail.com>
 <3e269bce8d73577fb1183697655d6ad66edf866f.camel@sipsolutions.net>
 <195E1629-BC72-4968-8E61-860C80F58D8B@gmail.com>
 <386f10e09c17b871df1c86ebc0c2af52938c6fb6.camel@sipsolutions.net>
To:     Johannes Berg <johannes@sipsolutions.net>
Precedence: bulk


> On 28. Feb 2023, at 18:41, Johannes Berg <johannes@sipsolutions.net> =
wrote:
>=20
> On Thu, 2023-01-26 at 15:26 +0100, Jonas Jelonek wrote:
>>>=20
>>> However, I think that for new parameters, there's really no good
>>> reason
>>> to provide module parameters, since the test scripting etc. can
>>> dynamically create wiphys with the necessary capabilities. Even the
>>> hostap/hwsim tests can and do already do that :)
>>=20
>> =46rom what I=E2=80=99ve seen there is no dynamic parameter for RCTBL =
yet but I
>> can combine
>> this with my additional TPC parameter. Then this can be set via
>> netlink.
>=20
> Fair enough, but yeah, I think we should move to that.
>=20
>>> We already have netlink support for setting per-station TX power
>>> which I guess this should then listen to? See
>>> NL80211_ATTR_STA_TX_POWER_SETTING
>>> and NL80211_ATTR_STA_TX_POWER etc. I think it's not supported in
>>> mac80211, but probably could easily be after your patches?
>>=20
>> I guess that can be part of some follow-up patches after these =
patches
>> here are upstream.
>> I would agree that this should somehow listen to the mentioned
>> attributes then.
>=20
> OK.
>=20
>> We want to do joint RC and TPC in minstrel, and to allow fine-grained
>> TPC as it is already possible with RC. Minstrel will also be adjusted =
in
>> one of the next steps.
>> This RFC basically should =E2=80=9Cprepare=E2=80=9D mac80211 to be =
used for fine-
>> grained TPC. I think, driver support and Minstrel support should be =
the
>> next steps after the structures are fixed.
>> But I include hwsim here to have at least a test-case. Hope you get
>> what I mean :)
>=20
> Yep, seems good.
>=20
> I'm slightly worried we'll add this and never get to do the minstrel
> part, but hey.

This is also part of our research so we are going to either implement =
TPC in
minstrel or export this to user space. Our research also includes =
looking at
doing RC + TPC in user space with more advanced algorithms.

> Also, most modern devices no longer even use minstrel, so is it even
> worth doing at all from that perspective? What's in it for the users
> who've been using their devices for years (since newer devices in the
> past few years haven't used it, I think) without it?
>=20
> johannes

Our goal and hope is that, we explore that and then can show some =
benefits of
more advanced RC and TPC algorithm, so vendors like Atheros and Mediatek
may again expose the MRR capabilities to the mac80211 layer with future
chips. Afaik, the last Mediatek chips supporting mrr rate setting are =
mt76xx, which
I guess are still pretty common, so we are doing our work on still =
relevant hardware.

After having a short look at the driver code, it seems like more recent =
chips (in
particular Mediatek) at least kept support for controlling the TX power =
per packet.
I am not sure if it could be a good idea to split that up, not having TX =
power in the
RC table but somehow separate. Then you would be able to do TPC without =
RC.

Jonas