| Message ID | 20220829144147.484787-1-jelonek.jonas@gmail.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | mac80211: add TPC support in control path | expand |
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
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
> 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
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
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
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 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
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
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
> 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
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
> 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
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(-)