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

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

[Jonas Jelonek]

Transmit power control (TPC) per packet hence per station can be used to
manage interference and increase overall spatial reuse and therefore
increases sum throughput in WiFi networks with multiple APs and STAs.
Although several of today's wifi chips, e.g., from QCA and from Mediatek
support fine-grained TPC per packet, the Linux mac80211 layer does not
provide support this annotation nor control yet.

This series proposes several changes to introduce TPC support in
mac80211, in particular to annotate tx-power per packet/per mrr stage in
the Tx control path.
The patches include new nembers in the Tx control path structs, a
modified tx-power level support annotation, hardware flags and an
utility function for the convenient use of struct ieee80211_rate_status
(introduced by 44fa75f207d8a106bc75e6230db61e961fdbf8a8) for tx-power
status report in drivers.

Compile-Tested: current wireless-next tree with all flags on
Tested-on PCEngines APU with ath9k WiFi device on OpenWrt Linux
        Kernel 5.10.137
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.

Signed-off-by: Thomas Huehn <thomas.huehn@hs-nordhausen.de>
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>

Jonas Jelonek (4):
  mac80211: modify tx-power level annotation
  mac80211: add tx-power annotation in control path
  mac80211: add hardware flags for TPC support
  mac80211: add utility function for tx_rate - rate_info conversion

 include/net/mac80211.h | 60 +++++++++++++++++++++++++++++++++++-------
 net/mac80211/debugfs.c |  2 ++
 net/mac80211/util.c    | 35 ++++++++++++++++++++++++
 3 files changed, 87 insertions(+), 10 deletions(-)

-- 
2.30.2

[RFC 1/4] mac80211: modify tx-power level annotation

[Jonas Jelonek]

This patch modifies the annotation of supported tx-power levels for a
wifi device in ieee80211_hw. This annotation was introduced with commit
44fa75f207d8a106bc75e6230db61e961fdbf8a8 to be able to operate on power
indices instead of absolute power values, providing better support for
different hardware capabilities.

The former annotation uses a 'const s8' for each power level. The choice
made with the former commit was not the best as this kind of annotation
may require much memory if there is a high number of power levels.
Thus, it is now replaced by a new struct ieee80211_hw_txpower_range. This
struct describes a tx-power range by specifying a start index, the number
of levels, a start power value and the power step width.

A wifi driver should specify valid tx-power ranges when it registers a
device in mac80211 by providing a pointer to a list and a length in the
corresponding ieee80211_hw members.
Drivers can define multiple tx-power ranges with each different scales
depending on the hardware.

Signed-off-by: Thomas Huehn <thomas.huehn@hs-nordhausen.de>
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
---
 include/net/mac80211.h | 32 ++++++++++++++++++++++++++------
 1 file changed, 26 insertions(+), 6 deletions(-)

diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index ffd0ebbff294..9612714d715f 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -2619,6 +2619,27 @@ enum ieee80211_hw_flags {
 	NUM_IEEE80211_HW_FLAGS
 };
 
+/**
+ * struct ieee80211_hw_txpower_range - Power range for transmit power
+ *
+ * This struct can be used by drivers to define multiple tx-power ranges with
+ * different scales according to the hardware capabilities. A tx-power range
+ * describe either absolute power levels or power offsets relative to a base
+ * power.
+ *
+ * @start_idx The starting idx of the range. @start_idx is always the lowest
+ * 	idx of the power range.
+ * @start_pwr The power level at idx @start_idx.
+ * @n_levels How many power levels this range has.
+ * @pwr_step The power step width in 0.25 dBm units.
+ */
+struct ieee80211_hw_txpower_range {
+	u8 start_idx;
+	u8 n_levels;
+	s8 start_pwr;
+	s8 pwr_step;
+};
+
 /**
  * struct ieee80211_hw - hardware information and state
  *
@@ -2741,11 +2762,10 @@ enum ieee80211_hw_flags {
  *
  * @max_mtu: the max mtu could be set.
  *
- * @tx_power_levels: a list of power levels supported by the wifi hardware.
- * 	The power levels can be specified either as integer or fractions.
- * 	The power level at idx 0 shall be the maximum positive power level.
+ * @txpower_ranges: a list of tx-power level ranges supported by the wifi
+ *  hardware. The driver can specify multiple ranges with e.g. different scales.
  *
- * @max_txpwr_levels_idx: the maximum valid idx of 'tx_power_levels' list.
+ * @n_txpower_ranges: the number of power ranges defined by the wifi driver.
  */
 struct ieee80211_hw {
 	struct ieee80211_conf conf;
@@ -2782,8 +2802,8 @@ struct ieee80211_hw {
 	u8 tx_sk_pacing_shift;
 	u8 weight_multiplier;
 	u32 max_mtu;
-	const s8 *tx_power_levels;
-	u8 max_txpwr_levels_idx;
+	struct ieee80211_hw_txpower_range *txpower_ranges;
+	u8 n_txpower_ranges;
 };
 
 static inline bool _ieee80211_hw_check(struct ieee80211_hw *hw,
-- 
2.30.2

[RFC 2/4] mac80211: add tx-power annotation in control path

[Jonas Jelonek]

This patch adds members to ieee80211_tx_info and ieee80211_sta_rates
structures to allow tx-power annotation per packet/per mrr stage.
The added members are always tx-power indices referring to the tx-power
set described by ieee80211_hw->txpower_ranges.

The annotation in ieee80211_tx_info is for probing and compatibility
reasons only, e.g. drivers that only support RC/TPC per packet and do
not yet use ieee80211_sta_rates.

Signed-off-by: Thomas Huehn <thomas.huehn@hs-nordhausen.de>
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
---
 include/net/mac80211.h | 15 +++++++++++----
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index 9612714d715f..659662f8b5dd 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -1072,6 +1072,8 @@ ieee80211_rate_get_vht_nss(const struct ieee80211_tx_rate *rate)
  * @control.use_cts_prot: use RTS/CTS
  * @control.short_preamble: use short preamble (CCK only)
  * @control.skip_table: skip externally configured rate table
+ * @control.txpower_idx: Tx-power level index for whole packet,
+ * 	referring to an idx described by ieee80211_hw->txpower_ranges
  * @control.jiffies: timestamp for expiry on powersave clients
  * @control.vif: virtual interface (may be NULL)
  * @control.hw_key: key to encrypt with (may be NULL)
@@ -1120,7 +1122,8 @@ struct ieee80211_tx_info {
 					u8 use_cts_prot:1;
 					u8 short_preamble:1;
 					u8 skip_table:1;
-					/* 2 bytes free */
+					u8 txpower_idx;
+					/* 1 byte free */
 				};
 				/* only needed before rate control */
 				unsigned long jiffies;
@@ -1181,9 +1184,10 @@ ieee80211_info_get_tx_time_est(struct ieee80211_tx_info *info)
  *
  * @rate_idx The actual used rate.
  * @try_count How often the rate was tried.
- * @tx_power_idx An idx into the ieee80211_hw->tx_power_levels list of the
- * 	corresponding wifi hardware. The idx shall point to the power level
- * 	that was used when sending the packet.
+ * @tx_power_idx An idx into the the tx-power set described by
+ * 	ieee80211_hw->txpower_ranges for the corresponding wifi hardware.
+ * 	The idx shall point to the tx-power level that was used when sending
+ * 	the packet.
  */
 struct ieee80211_rate_status {
 	struct rate_info rate_idx;
@@ -2097,6 +2101,8 @@ enum ieee80211_sta_rx_bandwidth {
  * @rcu_head: RCU head used for freeing the table on update
  * @rate: transmit rates/flags to be used by default.
  *	Overriding entries per-packet is possible by using cb tx control.
+ * @rate.txpower_idx: An idx pointing to a tx-power level described by
+ * 	ieee80211_hw->txpower_ranges that should be used for the mrr stage.
  */
 struct ieee80211_sta_rates {
 	struct rcu_head rcu_head;
@@ -2106,6 +2112,7 @@ struct ieee80211_sta_rates {
 		u8 count_cts;
 		u8 count_rts;
 		u16 flags;
+		u8 txpower_idx;
 	} rate[IEEE80211_TX_RATE_TABLE_SIZE];
 };
 
-- 
2.30.2

[RFC 3/4] mac80211: add hardware flags for TPC support

[Jonas Jelonek]

This patch adds two hardware flags for drivers to indicate their
transmit power control (TPC) capabilities: TPC per packet or TPC
per mrr stage of each data packet. The driver has to register with its
TPC capabilities when it is registering at the mac80211.

Signed-off-by: Thomas Huehn <thomas.huehn@hs-nordhausen.de>
Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
---
 include/net/mac80211.h | 9 +++++++++
 net/mac80211/debugfs.c | 2 ++
 2 files changed, 11 insertions(+)

diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index 659662f8b5dd..ce3241313e06 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -2564,6 +2564,13 @@ struct ieee80211_txq {
  * @IEEE80211_HW_MLO_MCAST_MULTI_LINK_TX: Hardware/driver handles transmitting
  *	multicast frames on all links, mac80211 should not do that.
  *
+ * @IEEE80211_HW_SUPPORTS_TPC_PER_PACKET: The hardware/driver supports transmit
+ * 	power control (TPC) with one power level per data packet.
+ *
+ * @IEEE80211_HW_SUPPORTS_TPC_PER_MRR: The hardware/driver supports transmit
+ * 	power control (TPC) with individual power levels for each
+ * 	multi-rate-retry (mrr) stage per packet.
+ *
  * @NUM_IEEE80211_HW_FLAGS: number of hardware flags, used for sizing arrays
  */
 enum ieee80211_hw_flags {
@@ -2621,6 +2628,8 @@ enum ieee80211_hw_flags {
 	IEEE80211_HW_SUPPORTS_CONC_MON_RX_DECAP,
 	IEEE80211_HW_DETECTS_COLOR_COLLISION,
 	IEEE80211_HW_MLO_MCAST_MULTI_LINK_TX,
+	IEEE80211_HW_SUPPORTS_TPC_PER_PACKET,
+	IEEE80211_HW_SUPPORTS_TPC_PER_MRR,
 
 	/* keep last, obviously */
 	NUM_IEEE80211_HW_FLAGS
diff --git a/net/mac80211/debugfs.c b/net/mac80211/debugfs.c
index 78c7d60e8667..daeef1e04cb5 100644
--- a/net/mac80211/debugfs.c
+++ b/net/mac80211/debugfs.c
@@ -496,6 +496,8 @@ static const char *hw_flag_names[] = {
 	FLAG(SUPPORTS_CONC_MON_RX_DECAP),
 	FLAG(DETECTS_COLOR_COLLISION),
 	FLAG(MLO_MCAST_MULTI_LINK_TX),
+	FLAG(SUPPORTS_TPC_PER_PACKET),
+	FLAG(SUPPORTS_TPC_PER_MRR),
 #undef FLAG
 };
 
-- 
2.30.2

[RFC 4/4] mac80211: add utility function for tx_rate - rate_info conversion

[Jonas Jelonek]

This patch adds an utility function to mac80211 for conversion between
ieee80211_tx_rate (mac80211.h) and rate_info (cfg80211.h).

struct ieee80211_tx_rate is space limited to annotate rates up to IEEE
802.11ac. The new struct rate_info is able to annotate IEEE 802.11ax
rates and beyond. Several drivers internally still use ieee80211_tx_rate
but mac80211 expects rate_info in struct ieee80211_rate_status. This
struct is in turn required to allow, e.g., tx-power status report or
dynamic number of mrr stages.

Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
---
 include/net/mac80211.h |  4 ++++
 net/mac80211/util.c    | 35 +++++++++++++++++++++++++++++++++++
 2 files changed, 39 insertions(+)

diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index ce3241313e06..cecba460a518 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -1050,6 +1050,10 @@ ieee80211_rate_get_vht_nss(const struct ieee80211_tx_rate *rate)
 	return (rate->idx >> 4) + 1;
 }
 
+void ieee80211_rate_get_rate_info(const struct ieee80211_tx_rate *rate,
+				  struct wiphy *wiphy, u8 band,
+				  struct rate_info *rate_info);
+
 /**
  * struct ieee80211_tx_info - skb transmit information
  *
diff --git a/net/mac80211/util.c b/net/mac80211/util.c
index a292e63377c3..466d49ff8dcf 100644
--- a/net/mac80211/util.c
+++ b/net/mac80211/util.c
@@ -4870,3 +4870,38 @@ void ieee80211_fragment_element(struct sk_buff *skb, u8 *len_pos)
 
 	*len_pos = elem_len;
 }
+
+
+void ieee80211_rate_get_rate_info(const struct ieee80211_tx_rate *rate,
+				  struct wiphy *wiphy, u8 band,
+				  struct rate_info *rate_info)
+{
+	memset(rate_info, 0, sizeof(struct rate_info));
+
+	if (rate->flags & IEEE80211_TX_RC_MCS) { /* 802.11n */
+		rate_info->flags |= RATE_INFO_FLAGS_MCS;
+		rate_info->mcs = rate->idx;
+	} else if (rate->flags & IEEE80211_TX_RC_VHT_MCS) { /* 802.11ac */
+		rate_info->flags |= RATE_INFO_FLAGS_VHT_MCS;
+		rate_info->mcs = ieee80211_rate_get_vht_mcs(rate);
+		rate_info->nss = ieee80211_rate_get_vht_nss(rate);
+	} else { /* 802.11a/b/g */
+		rate_info->legacy = wiphy->bands[band]->bitrates[rate->idx].bitrate;
+		rate_info->bw = RATE_INFO_BW_20;
+		return;
+	}
+
+	if (rate->flags & IEEE80211_TX_RC_40_MHZ_WIDTH)
+		rate_info->bw = RATE_INFO_BW_40;
+	else if (rate->flags & IEEE80211_TX_RC_80_MHZ_WIDTH)
+		rate_info->bw = RATE_INFO_BW_80;
+	else if (rate->flags & IEEE80211_TX_RC_160_MHZ_WIDTH)
+		rate_info->bw = RATE_INFO_BW_160;
+	else
+		rate_info->bw = RATE_INFO_BW_20;
+
+	if (rate->flags & IEEE80211_TX_RC_SHORT_GI)
+		rate_info->flags |= RATE_INFO_FLAGS_SHORT_GI;
+
+}
+EXPORT_SYMBOL(ieee80211_rate_get_rate_info);
-- 
2.30.2

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

[Johannes Berg]

On Mon, 2022-08-29 at 16:41 +0200, Jonas Jelonek wrote:
> Transmit power control (TPC) per packet hence per station can be used to
> manage interference and increase overall spatial reuse and therefore
> increases sum throughput in WiFi networks with multiple APs and STAs.
> Although several of today's wifi chips, e.g., from QCA and from Mediatek
> support fine-grained TPC per packet, the Linux mac80211 layer does not
> provide support this annotation nor control yet.
> 
> This series proposes several changes to introduce TPC support in
> mac80211, in particular to annotate tx-power per packet/per mrr stage in
> the Tx control path.
> The patches include new nembers in the Tx control path structs, a
> modified tx-power level support annotation, hardware flags and an
> utility function for the convenient use of struct ieee80211_rate_status
> (introduced by 44fa75f207d8a106bc75e6230db61e961fdbf8a8) for tx-power
> status report in drivers.
> 
> Compile-Tested: current wireless-next tree with all flags on
> Tested-on PCEngines APU with ath9k WiFi device on OpenWrt Linux
>         Kernel 5.10.137
> 

That seems just a little old? Not sure I'd trust that given the major
changes in the tree recently?

johannes

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

[Johannes Berg]

On Mon, 2022-08-29 at 16:41 +0200, Jonas Jelonek wrote:
> 
> 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.
> 

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?

johannes

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

[Thomas Hühn]

> On 29. Aug 2022, at 16:45, Johannes Berg <johannes@sipsolutions.net> wrote:
> 
> On Mon, 2022-08-29 at 16:41 +0200, Jonas Jelonek wrote:
>> Transmit power control (TPC) per packet hence per station can be used to
>> manage interference and increase overall spatial reuse and therefore
>> increases sum throughput in WiFi networks with multiple APs and STAs.
>> Although several of today's wifi chips, e.g., from QCA and from Mediatek
>> support fine-grained TPC per packet, the Linux mac80211 layer does not
>> provide support this annotation nor control yet.
>> 
>> This series proposes several changes to introduce TPC support in
>> mac80211, in particular to annotate tx-power per packet/per mrr stage in
>> the Tx control path.
>> The patches include new nembers in the Tx control path structs, a
>> modified tx-power level support annotation, hardware flags and an
>> utility function for the convenient use of struct ieee80211_rate_status
>> (introduced by 44fa75f207d8a106bc75e6230db61e961fdbf8a8) for tx-power
>> status report in drivers.
>> 
>> Compile-Tested: current wireless-next tree with all flags on
>> Tested-on PCEngines APU with ath9k WiFi device on OpenWrt Linux
>>        Kernel 5.10.137
>> 
> 
> That seems just a little old? Not sure I'd trust that given the major
> changes in the tree recently?

Good point, we can test this with 5.15.63 by enabling the OpenWrt testing kernel … would that be ok ?

> 
> johannes


Greetings Thomas

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

[Johannes Berg]

On Mon, 2022-08-29 at 16:51 +0200, Thomas Hühn wrote:
> > > 
> > > Compile-Tested: current wireless-next tree with all flags on
> > > Tested-on PCEngines APU with ath9k WiFi device on OpenWrt Linux
> > >        Kernel 5.10.137
> > > 
> > 
> > That seems just a little old? Not sure I'd trust that given the major
> > changes in the tree recently?
> 
> Good point, we can test this with 5.15.63 by enabling the OpenWrt testing kernel … would that be ok ?
> 

Well a lot of major changes just happened 5.19 -> 6.0, so something more
recent would be better?

johannes

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

[Johannes Berg]

On Mon, 2022-08-29 at 16:52 +0200, Johannes Berg wrote:
> On Mon, 2022-08-29 at 16:51 +0200, Thomas Hühn wrote:
> > > > 
> > > > Compile-Tested: current wireless-next tree with all flags on
> > > > Tested-on PCEngines APU with ath9k WiFi device on OpenWrt Linux
> > > >        Kernel 5.10.137
> > > > 
> > > 
> > > That seems just a little old? Not sure I'd trust that given the major
> > > changes in the tree recently?
> > 
> > Good point, we can test this with 5.15.63 by enabling the OpenWrt testing kernel … would that be ok ?
> > 
> 
> Well a lot of major changes just happened 5.19 -> 6.0, so something more
> recent would be better?
> 

Maybe you could add support in hwsim?

johannes

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

[Jonas Jelonek]

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 
top of this once all is reviewed, approved and upstream. 
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’s debugfs to be able to set 
fixed tx-power per STA.

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. 
Else we could also provide at least a debugfs patch to be able to set fixed
tx-power per STA.

Greetings
Jonas

> On 29. Aug 2022, at 16:46, Johannes Berg <johannes@sipsolutions.net> wrote:
> 
> On Mon, 2022-08-29 at 16:41 +0200, Jonas Jelonek wrote:
>> 
>> 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.
>> 
> 
> 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?
> 
> johannes

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

[Jonas Jelonek]

I compile-tested with up-to-date wireless-next, should be 6.0?
Is this sufficient?

The changes in mac80211 regarding status path from me that were part of 5.19
were manually included in my OpenWrt test, other changes not. We can definitely
try with the OpenWrt testing kernel as Thomas mentioned.

Greetings
Jonas

> On 29. Aug 2022, at 16:52, Johannes Berg <johannes@sipsolutions.net> wrote:
> 
> On Mon, 2022-08-29 at 16:51 +0200, Thomas Hühn wrote:
>>>> 
>>>> Compile-Tested: current wireless-next tree with all flags on
>>>> Tested-on PCEngines APU with ath9k WiFi device on OpenWrt Linux
>>>>       Kernel 5.10.137
>>>> 
>>> 
>>> That seems just a little old? Not sure I'd trust that given the major
>>> changes in the tree recently?
>> 
>> Good point, we can test this with 5.15.63 by enabling the OpenWrt testing kernel … would that be ok ?
>> 
> 
> Well a lot of major changes just happened 5.19 -> 6.0, so something more
> recent would be better?
> 
> johannes

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

[Jonas Jelonek]

Good point, definitely makes sense.

Would this be sufficient as an implementation for this RFC?

Greetings
Jonas

> On 29. Aug 2022, at 16:52, Johannes Berg <johannes@sipsolutions.net> wrote:
> 
> On Mon, 2022-08-29 at 16:52 +0200, Johannes Berg wrote:
>> On Mon, 2022-08-29 at 16:51 +0200, Thomas Hühn wrote:
>>>>> 
>>>>> Compile-Tested: current wireless-next tree with all flags on
>>>>> Tested-on PCEngines APU with ath9k WiFi device on OpenWrt Linux
>>>>>       Kernel 5.10.137
>>>>> 
>>>> 
>>>> That seems just a little old? Not sure I'd trust that given the major
>>>> changes in the tree recently?
>>> 
>>> Good point, we can test this with 5.15.63 by enabling the OpenWrt testing kernel … would that be ok ?
>>> 
>> 
>> Well a lot of major changes just happened 5.19 -> 6.0, so something more
>> recent would be better?
>> 
> 
> Maybe you could add support in hwsim?
> 
> johannes

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

[Thomas Hühn]

hiho

> On 29. Aug 2022, at 17:19, Jonas Jelonek <jelonek.jonas@gmail.com> wrote:
> 
> Good point, definitely makes sense.
> 
> Would this be sufficient as an implementation for this RFC?
> 
> Greetings
> Jonas

lets stick to not doing top posts ;)

> 
>> On 29. Aug 2022, at 16:52, Johannes Berg <johannes@sipsolutions.net> wrote:
>> 
>> On Mon, 2022-08-29 at 16:52 +0200, Johannes Berg wrote:
>>> On Mon, 2022-08-29 at 16:51 +0200, Thomas Hühn wrote:
>>>>>> 
>>>>>> Compile-Tested: current wireless-next tree with all flags on
>>>>>> Tested-on PCEngines APU with ath9k WiFi device on OpenWrt Linux
>>>>>>      Kernel 5.10.137
>>>>>> 
>>>>> 
>>>>> That seems just a little old? Not sure I'd trust that given the major
>>>>> changes in the tree recently?
>>>> 
>>>> Good point, we can test this with 5.15.63 by enabling the OpenWrt testing kernel … would that be ok ?
>>>> 
>>> 
>>> Well a lot of major changes just happened 5.19 -> 6.0, so something more
>>> recent would be better?
>>> 
>> 
>> Maybe you could add support in hwsim?
>> 

hwsim support is a good idea for this patch series and probably a debugfs to annotate static power levels per sta.
We are working on a joint rate and power algorithm, but that is quit a big change on its own and probably better reviewable
in a seperate patch series after this one that enabled the tpc annotation parts.


Greetings Thomas

>> johannes
> 

—
Prof. Dr.-Ing. Thomas Hühn

Hochschule Nordhausen
Fachbereich Ingenieurwissenschaften - Institut für Informatik, Automatisierung und Elektronik 
Leitung Kommunikationstechnik und Bussysteme

Weinberghof 4
99734 Nordhausen, Germany

Tel: +49 3631 420 318
Fax: +49 3631 420 818

thomas.huehn@hs-nordhausen.de
www.hs-nordhausen.de

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

[Jonas Jelonek]

> On 29. Aug 2022, at 17:06, Jonas Jelonek <jelonek.jonas@gmail.com> wrote:
> 
> 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 
> top of this once all is reviewed, approved and upstream. 
> 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’s debugfs to be able to set 
> fixed tx-power per STA.
> 
> 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. 
> Else we could also provide at least a debugfs patch to be able to set fixed
> tx-power per STA.
> 
> Greetings
> Jonas
> 
>> On 29. Aug 2022, at 16:46, Johannes Berg <johannes@sipsolutions.net> wrote:
>> 
>> On Mon, 2022-08-29 at 16:41 +0200, Jonas Jelonek wrote:
>>> 
>>> 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.
>>> 
>> 
>> 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?
>> 
>> johannes
> 

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?

Greetings
Jonas

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

[Johannes Berg]

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

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

[Jonas Jelonek]

> 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