Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Content-Type: text/plain;
        charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.100.31\))
Subject: Re: [RFC 0/4] mac80211: add TPC support in control path
From:   Jonas Jelonek <jelonek.jonas@gmail.com>
In-Reply-To: <CE871D89-B996-4D8B-8C65-7C53382C30D8@gmail.com>
Date:   Wed, 31 Aug 2022 15:59:26 +0200
Cc:     linux-wireless@vger.kernel.org, nbd@nbd.name,
        =?utf-8?Q?Thomas_H=C3=BChn?= <thomas.huehn@hs-nordhausen.de>
Content-Transfer-Encoding: quoted-printable
Message-Id: <7CFDCFCC-A369-4F41-90E1-A26591C20D92@gmail.com>
References: <20220829144147.484787-1-jelonek.jonas@gmail.com>
 <467218ec220ea6e36b4222efc5c46e4e350fe1ea.camel@sipsolutions.net>
 <CE871D89-B996-4D8B-8C65-7C53382C30D8@gmail.com>
To:     Johannes Berg <johannes@sipsolutions.net>
Precedence: bulk


> On 29. Aug 2022, at 17:06, Jonas Jelonek <jelonek.jonas@gmail.com> =
wrote:
>=20
> We planned to get these changes upstream at first to have the =
foundation for TPC
> in the mac80211, and then develop driver implementations and TPC =
algorithm on=20
> top of this once all is reviewed, approved and upstream.=20
> The ath9k tpc support is currently not upstream-ready but can be in a =
next version.
> For testing the actual TPC support I modified minstrel=E2=80=99s =
debugfs to be able to set=20
> fixed tx-power per STA.
>=20
> I think we can develop this series further to come up with fully =
working driver
> implementation and a TPC algorithm if you think that would be better.=20=

> Else we could also provide at least a debugfs patch to be able to set =
fixed
> tx-power per STA.
>=20
> Greetings
> Jonas
>=20
>> On 29. Aug 2022, at 16:46, Johannes Berg <johannes@sipsolutions.net> =
wrote:
>>=20
>> On Mon, 2022-08-29 at 16:41 +0200, Jonas Jelonek wrote:
>>>=20
>>> I tested the tx-power annotation with an implementation of TPC in =
ath9k
>>> (not included in this RFC) and small changes in minstrel_ht for =
debugfs
>>> access. Tx-power status report in ath9k required the proposed =
utility
>>> function in mac80211.
>>>=20
>>=20
>> Huh wait, now that I got to the end of the series ... this doesn't
>> actually *do* anything, so what's the point? Shouldn't it come with =
some
>> implementation of the control?
>>=20
>> johannes
>=20

I am working on the hwsim support right now, tpc support in hwsim=E2=80=99=
s control path is implemented.
However I encountered a problem in the status path. Hwsim seems to hand =
over to mac80211
tx-status asynchronously via ieee80211_tx_status_irqsafe only. There, =
the skb is added to
ieee80211_local->skb_queue and then dequeued in =
=E2=80=98ieee80211_tasklet_handler=E2=80=99 to be passed
to =E2=80=98ieee80211_tx_status=E2=80=99. For tx rates this is =
sufficient, but there is no space left in=20
ieee80211_tx_info->status to pass the tx-power per packet.
Please correct me if I missed something in the code.

My idea to solve this may be: to use the SKB extension (struct skb_ext =
*extensions) to pass the=20
tx-power information (and maybe more) for each SKB. Could this be an =
appropriate approach or=20
do I miss something here? Maybe someone who is much more aware of the =
mac80211 layer=20
design does have a better idea for this?

Greetings
Jonas=