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: <c9befe233be586eb2c949f7301784e948c3a6683.camel@sipsolutions.net>
Date:   Wed, 31 Aug 2022 17:39:17 +0200
Cc:     linux-wireless@vger.kernel.org, Felix Fietkau <nbd@nbd.name>,
        =?utf-8?Q?Thomas_H=C3=BChn?= <thomas.huehn@hs-nordhausen.de>
Content-Transfer-Encoding: quoted-printable
Message-Id: <0EF20938-8E10-4846-B280-37054898441A@gmail.com>
References: <20220829144147.484787-1-jelonek.jonas@gmail.com>
 <467218ec220ea6e36b4222efc5c46e4e350fe1ea.camel@sipsolutions.net>
 <CE871D89-B996-4D8B-8C65-7C53382C30D8@gmail.com>
 <7CFDCFCC-A369-4F41-90E1-A26591C20D92@gmail.com>
 <c9befe233be586eb2c949f7301784e948c3a6683.camel@sipsolutions.net>
To:     Johannes Berg <johannes@sipsolutions.net>
Precedence: bulk


> On 31. Aug 2022, at 16:22, Johannes Berg <johannes@sipsolutions.net> =
wrote:
>=20
> Sorry I dropped out of the thread - busy with other stuff. I'll reply =
to
> other mails later.
>=20
>> I am working on the hwsim support right now, tpc support in hwsim=E2=80=
=99s
>> 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.
>>=20
>> 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?
>=20
> Is it even an issue to switch to ieee80211_tx_status_ext()? The =
context
> here looks OK, although it might lead to (too?) deep call stacks.
>=20
> I don't like the _irqsafe() versions anyway =E2=80=A6
>=20
> johannes

I am not sure about this _irqsafe() thing, just assumed there is/was a =
reason they
are used instead of the normal ones. Would definitely be the easier =
option to
have ieee80211_tx_status_ext() for this RFC and future extensions. I =
could have
a closer look into this, or someone else knows if this could cause an =
issue. Same
for call stack depth.

Greetings
Jonas=