Re: [RFC 0/4] mac80211: add TPC support in control path

[Jonas Jelonek <jelonek.jonas@gmail.com>]

> On 31. Aug 2022, at 16:22, Johannes Berg <johannes@sipsolutions.net> wrote:
> 
> Sorry I dropped out of the thread - busy with other stuff. I'll reply to
> other mails later.
> 
>> I am working on the hwsim support right now, tpc support in hwsim’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
>> ‘ieee80211_tasklet_handler’ to be passed
>> to ‘ieee80211_tx_status’. For tx rates this is sufficient, but there
>> is no space left in 
>> 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 
>> tx-power information (and maybe more) for each SKB. Could this be an
>> appropriate approach or 
>> do I miss something here? Maybe someone who is much more aware of the
>> mac80211 layer 
>> design does have a better idea for this?
> 
> 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.
> 
> I don't like the _irqsafe() versions anyway …
> 
> 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