Content-Type: text/plain;
        charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.300.101.1.3\))
Subject: Re: [RFC v2 5/6] mac80211_hwsim: add TPC per packet support
From:   Jonas Jelonek <jelonek.jonas@gmail.com>
In-Reply-To: <3e269bce8d73577fb1183697655d6ad66edf866f.camel@sipsolutions.net>
Date:   Thu, 26 Jan 2023 17:52:21 +0100
Cc:     linux-wireless@vger.kernel.org, Felix Fietkau <nbd@nbd.name>
Content-Transfer-Encoding: quoted-printable
Message-Id: <E26F68F9-337D-4163-AA0F-A43E50864AEB@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>
To:     Johannes Berg <johannes@sipsolutions.net>
Precedence: bulk


> On 19. Jan 2023, at 16:09, Johannes Berg <johannes@sipsolutions.net> =
wrote:
>=20
> On Thu, 2023-01-19 at 15:32 +0100, Jonas Jelonek wrote:
>>>=20
>>> Not sure I like this either - I think we should probably create the
>>> wiphys dynamically for most features these days?
>>=20
>> just to make sure I got it correctly: so you propose that these
>> params, that are=20
>> currently done with module_param(), should be switched to a dynamic
>> netlink approach, or only for TPC and RCTBL for now?
>=20
> We do have dynamic parameters for all the module parameters I believe,
> but we've shied away from actually removing the existing module
> parameters for legacy/compatibility reasons.
>=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 :)

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

>> As a first step I focused on providing a proof-of-concept
>> implementation in hwsim for my
>> TPC proposal, implementing netlink to set tx power and other could be
>> part of the next step.
>> Do you think this could be fine or do you propose something =
different?
>=20
> I'm not quite sure what you mean by that, tbh. I guess I kind of =
thought
> you were going to adjust minstrel to do TPC automatically.
>=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?

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.

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 :)

Jonas