diff mbox

[2/2] ath10k: add per peer tx stats support for 10.2.4

Message ID 1512046701-14435-3-git-send-email-akolli@qti.qualcomm.com (mailing list archive)
State New, archived
Headers show

Commit Message

akolli@qti.qualcomm.com Nov. 30, 2017, 12:58 p.m. UTC
From: Anilkumar Kolli <akolli@qti.qualcomm.com>

10.2.4 firmware branch (used in QCA988X) does not support
HTT_10_4_T2H_MSG_TYPE_PEER_STATS and that's why ath10k does not provide
tranmission rate statistics to user space, instead it just shows
hardcoded 6 Mbit/s. But pktlog firmware facility provides per peer tx
statistics. The firmware sends one pktlog event for every four
PPDUs per peer, which include:

* successful number of packets and bytes transmitted
* number of packets and bytes dropped
* retried number of packets and bytes
* rate info per ppdu

Firmware supports WMI_SERVICE_PEER_STATS, pktlog is enabled through
ATH10K_FLAG_PEER_STATS, which is nowadays enabled by default in ath10k.

This patch does not impact throughput.

Tested on QCA9880 with firmware version 10.2.4.70.48. This should also
work with firmware branch 10.2.4-1.0-00029

Parse peer stats from pktlog packets and update the tx rate information
per STA. This way user space can query about transmit rate with iw:

$iw wlan0 station dump
Station 3c:a9:f4:72:bb:a4 (on wlan1)
        inactive time:  8210 ms
        rx bytes:       9166
        rx packets:     44
        tx bytes:       1105
        tx packets:     9
        tx retries:     0
        tx failed:      1
        rx drop misc:   3
        signal:         -75 [-75, -87, -88] dBm
        signal avg:     -75 [-75, -85, -88] dBm
        tx bitrate:     39.0 MBit/s MCS 10
        rx bitrate:     26.0 MBit/s MCS 3
        rx duration:    23250 us
        authorized:     yes
        authenticated:  yes
        associated:     yes
        preamble:       short
        WMM/WME:        yes
        MFP:            no
        TDLS peer:      no
        DTIM period:    2
        beacon interval:100
        short preamble: yes
        short slot time:yes
        connected time: 22 seconds

Signed-off-by: Anilkumar Kolli <akolli@qti.qualcomm.com>
---
 drivers/net/wireless/ath/ath10k/debug.h  |   18 ++++++++-
 drivers/net/wireless/ath/ath10k/htt.h    |   17 +++++++++
 drivers/net/wireless/ath/ath10k/htt_rx.c |   60 ++++++++++++++++++++++++++++++
 drivers/net/wireless/ath/ath10k/mac.c    |   10 +++++
 4 files changed, 104 insertions(+), 1 deletion(-)

Comments

Kalle Valo Nov. 30, 2017, 4:14 p.m. UTC | #1
<akolli@qti.qualcomm.com> writes:

> From: Anilkumar Kolli <akolli@qti.qualcomm.com>
>
> 10.2.4 firmware branch (used in QCA988X) does not support
> HTT_10_4_T2H_MSG_TYPE_PEER_STATS and that's why ath10k does not provide
> tranmission rate statistics to user space, instead it just shows
> hardcoded 6 Mbit/s. But pktlog firmware facility provides per peer tx
> statistics. The firmware sends one pktlog event for every four
> PPDUs per peer, which include:
>
> * successful number of packets and bytes transmitted
> * number of packets and bytes dropped
> * retried number of packets and bytes
> * rate info per ppdu
>
> Firmware supports WMI_SERVICE_PEER_STATS, pktlog is enabled through
> ATH10K_FLAG_PEER_STATS, which is nowadays enabled by default in ath10k.
>
> This patch does not impact throughput.
>
> Tested on QCA9880 with firmware version 10.2.4.70.48. This should also
> work with firmware branch 10.2.4-1.0-00029
>
> Parse peer stats from pktlog packets and update the tx rate information
> per STA. This way user space can query about transmit rate with iw:
>
> $iw wlan0 station dump
> Station 3c:a9:f4:72:bb:a4 (on wlan1)
>         inactive time:  8210 ms
>         rx bytes:       9166
>         rx packets:     44
>         tx bytes:       1105
>         tx packets:     9
>         tx retries:     0
>         tx failed:      1
>         rx drop misc:   3
>         signal:         -75 [-75, -87, -88] dBm
>         signal avg:     -75 [-75, -85, -88] dBm
>         tx bitrate:     39.0 MBit/s MCS 10
>         rx bitrate:     26.0 MBit/s MCS 3
>         rx duration:    23250 us
>         authorized:     yes
>         authenticated:  yes
>         associated:     yes
>         preamble:       short
>         WMM/WME:        yes
>         MFP:            no
>         TDLS peer:      no
>         DTIM period:    2
>         beacon interval:100
>         short preamble: yes
>         short slot time:yes
>         connected time: 22 seconds
>
> Signed-off-by: Anilkumar Kolli <akolli@qti.qualcomm.com>

[...]

> +struct ath10k_10_2_peer_tx_stats {
> +	u8 ratecode[PEER_STATS_FOR_NO_OF_PPDUS];
> +	u8 success_pkts[PEER_STATS_FOR_NO_OF_PPDUS];
> +	__le16 success_bytes[PEER_STATS_FOR_NO_OF_PPDUS];
> +	u8 retry_pkts[PEER_STATS_FOR_NO_OF_PPDUS];
> +	__le16 retry_bytes[PEER_STATS_FOR_NO_OF_PPDUS];
> +	u8 failed_pkts[PEER_STATS_FOR_NO_OF_PPDUS];
> +	__le16 failed_bytes[PEER_STATS_FOR_NO_OF_PPDUS];
> +	u8 flags[PEER_STATS_FOR_NO_OF_PPDUS];
> +	__le32 tx_duration;
> +	u8 tx_ppdu_cnt;
> +	u8 peer_id;
> +} __packed;

Toke, hopefully the tx_duration value here helps with ATF implementation
using QCA988X.
Toke Høiland-Jørgensen Nov. 30, 2017, 4:28 p.m. UTC | #2
>> +struct ath10k_10_2_peer_tx_stats {
>> +	u8 ratecode[PEER_STATS_FOR_NO_OF_PPDUS];
>> +	u8 success_pkts[PEER_STATS_FOR_NO_OF_PPDUS];
>> +	__le16 success_bytes[PEER_STATS_FOR_NO_OF_PPDUS];
>> +	u8 retry_pkts[PEER_STATS_FOR_NO_OF_PPDUS];
>> +	__le16 retry_bytes[PEER_STATS_FOR_NO_OF_PPDUS];
>> +	u8 failed_pkts[PEER_STATS_FOR_NO_OF_PPDUS];
>> +	__le16 failed_bytes[PEER_STATS_FOR_NO_OF_PPDUS];
>> +	u8 flags[PEER_STATS_FOR_NO_OF_PPDUS];
>> +	__le32 tx_duration;
>> +	u8 tx_ppdu_cnt;
>> +	u8 peer_id;
>> +} __packed;
>
>Toke, hopefully the tx_duration value here helps with ATF
>implementation
>using QCA988X.

Awesome! What's the semantics of this field? Just total 
duration spent serving that station in the reporting interval?
Does it include retry attempts?

-Toke
Kalle Valo Nov. 30, 2017, 4:38 p.m. UTC | #3
Toke Høiland-Jørgensen <toke@toke.dk> writes:

>>> +struct ath10k_10_2_peer_tx_stats {

>>> +	u8 ratecode[PEER_STATS_FOR_NO_OF_PPDUS];

>>> +	u8 success_pkts[PEER_STATS_FOR_NO_OF_PPDUS];

>>> +	__le16 success_bytes[PEER_STATS_FOR_NO_OF_PPDUS];

>>> +	u8 retry_pkts[PEER_STATS_FOR_NO_OF_PPDUS];

>>> +	__le16 retry_bytes[PEER_STATS_FOR_NO_OF_PPDUS];

>>> +	u8 failed_pkts[PEER_STATS_FOR_NO_OF_PPDUS];

>>> +	__le16 failed_bytes[PEER_STATS_FOR_NO_OF_PPDUS];

>>> +	u8 flags[PEER_STATS_FOR_NO_OF_PPDUS];

>>> +	__le32 tx_duration;

>>> +	u8 tx_ppdu_cnt;

>>> +	u8 peer_id;

>>> +} __packed;

>>

>>Toke, hopefully the tx_duration value here helps with ATF

>>implementation

>>using QCA988X.

>

> Awesome! What's the semantics of this field? Just total 

> duration spent serving that station in the reporting interval?

> Does it include retry attempts?


I have no clue :) I just noticed this while I was reviewing the patch
internally and immediately recalled our discussions at Seoul. I can try
to find out, but that will take a long time as I have way too much stuff
pending at the moment. Hopefully someone more knowledgeable (Anilkumar?)
can chime in and help.

-- 
Kalle Valo
Anilkumar Kolli Dec. 1, 2017, 4:23 a.m. UTC | #4
On 2017-11-30 22:08, Kalle Valo wrote:
> Toke Høiland-Jørgensen <toke@toke.dk> writes:
> 
>>>> +struct ath10k_10_2_peer_tx_stats {
>>>> +	u8 ratecode[PEER_STATS_FOR_NO_OF_PPDUS];
>>>> +	u8 success_pkts[PEER_STATS_FOR_NO_OF_PPDUS];
>>>> +	__le16 success_bytes[PEER_STATS_FOR_NO_OF_PPDUS];
>>>> +	u8 retry_pkts[PEER_STATS_FOR_NO_OF_PPDUS];
>>>> +	__le16 retry_bytes[PEER_STATS_FOR_NO_OF_PPDUS];
>>>> +	u8 failed_pkts[PEER_STATS_FOR_NO_OF_PPDUS];
>>>> +	__le16 failed_bytes[PEER_STATS_FOR_NO_OF_PPDUS];
>>>> +	u8 flags[PEER_STATS_FOR_NO_OF_PPDUS];
>>>> +	__le32 tx_duration;
>>>> +	u8 tx_ppdu_cnt;
>>>> +	u8 peer_id;
>>>> +} __packed;
>>> 
>>> Toke, hopefully the tx_duration value here helps with ATF
>>> implementation
>>> using QCA988X.
>> 
>> Awesome! What's the semantics of this field? Just total
>> duration spent serving that station in the reporting interval?
>> Does it include retry attempts?
> 
> I have no clue :) I just noticed this while I was reviewing the patch
> internally and immediately recalled our discussions at Seoul. I can try
> to find out, but that will take a long time as I have way too much 
> stuff
> pending at the moment. Hopefully someone more knowledgeable 
> (Anilkumar?)
> can chime in and help.

tx_duration is aggregate time duration of 4 PPDU sent to STA.
FW sends these values for retry packets also.

Thanks,
Anil.
Maxime Bizon Dec. 1, 2017, 10:45 a.m. UTC | #5
On Thu, 2017-11-30 at 18:28 +0530, akolli@qti.qualcomm.com wrote:

Hello,

> Tested on QCA9880 with firmware version 10.2.4.70.48. This should also
> work with firmware branch 10.2.4-1.0-00029

I tried using your patch on 4.14 with firmware 10.2.4-1.0-00029

> Parse peer stats from pktlog packets and update the tx rate information
> per STA. This way user space can query about transmit rate with iw:

everything works ok, ath10k_update_per_peer_tx_stats() is called and
ath10k_sta fields are updated correctly

but tx bitrate is still 6 MBit/s in station dump

 # iw dev wlan1 station dump
Station e4:42:a6:24:c8:95 (on wlan1)
	inactive time:	0 ms
	rx bytes:	222415
	rx packets:	1678
	tx bytes:	8511140
	tx packets:	5828
	tx retries:	0
	tx failed:	4
	rx drop misc:	2
	signal:  	-39 [-54, -56, -39] dBm
	signal avg:	-39 [-53, -55, -39] dBm
	tx bitrate:	6.0 MBit/s
	rx bitrate:	360.0 MBit/s VHT-MCS 8 40MHz short GI VHT-NSS 2
	authorized:	yes
	authenticated:	yes
	associated:	yes
	preamble:	long
	WMM/WME:	yes
	MFP:		no
	TDLS peer:	no
	DTIM period:	2
	beacon interval:96
	short slot time:yes
	connected time:	1136 seconds

I see that ath10k does not implement ->dump_station callback, so which
part of the code updates the generic "struct station_info" fields ?

Am I missing a patch ?

Thanks
Toke Høiland-Jørgensen Dec. 1, 2017, 1:41 p.m. UTC | #6
akolli@codeaurora.org writes:

> On 2017-11-30 22:08, Kalle Valo wrote:
>> Toke Høiland-Jørgensen <toke@toke.dk> writes:
>> 
>>>>> +struct ath10k_10_2_peer_tx_stats {
>>>>> +	u8 ratecode[PEER_STATS_FOR_NO_OF_PPDUS];
>>>>> +	u8 success_pkts[PEER_STATS_FOR_NO_OF_PPDUS];
>>>>> +	__le16 success_bytes[PEER_STATS_FOR_NO_OF_PPDUS];
>>>>> +	u8 retry_pkts[PEER_STATS_FOR_NO_OF_PPDUS];
>>>>> +	__le16 retry_bytes[PEER_STATS_FOR_NO_OF_PPDUS];
>>>>> +	u8 failed_pkts[PEER_STATS_FOR_NO_OF_PPDUS];
>>>>> +	__le16 failed_bytes[PEER_STATS_FOR_NO_OF_PPDUS];
>>>>> +	u8 flags[PEER_STATS_FOR_NO_OF_PPDUS];
>>>>> +	__le32 tx_duration;
>>>>> +	u8 tx_ppdu_cnt;
>>>>> +	u8 peer_id;
>>>>> +} __packed;
>>>> 
>>>> Toke, hopefully the tx_duration value here helps with ATF
>>>> implementation
>>>> using QCA988X.
>>> 
>>> Awesome! What's the semantics of this field? Just total
>>> duration spent serving that station in the reporting interval?
>>> Does it include retry attempts?
>> 
>> I have no clue :) I just noticed this while I was reviewing the patch
>> internally and immediately recalled our discussions at Seoul. I can try
>> to find out, but that will take a long time as I have way too much 
>> stuff
>> pending at the moment. Hopefully someone more knowledgeable 
>> (Anilkumar?)
>> can chime in and help.
>
> tx_duration is aggregate time duration of 4 PPDU sent to STA.
> FW sends these values for retry packets also.

Great, that sounds like just what we need. Thanks for the pointer :)

-Toke
Anilkumar Kolli Dec. 1, 2017, 1:48 p.m. UTC | #7
Hello,

Thanks for verifying the patch.

On 2017-12-01 16:15, Maxime Bizon wrote:
> On Thu, 2017-11-30 at 18:28 +0530, akolli@qti.qualcomm.com wrote:
> 
> Hello,
> 
>> Tested on QCA9880 with firmware version 10.2.4.70.48. This should also
>> work with firmware branch 10.2.4-1.0-00029
> 
> I tried using your patch on 4.14 with firmware 10.2.4-1.0-00029
> 
I will test update.

>> Parse peer stats from pktlog packets and update the tx rate 
>> information
>> per STA. This way user space can query about transmit rate with iw:
> 
> everything works ok, ath10k_update_per_peer_tx_stats() is called and
> ath10k_sta fields are updated correctly
> 
> but tx bitrate is still 6 MBit/s in station dump
> 
Hope CONFIG_MAC80211_DEBUGFS is enabled in your build.
Please Run ping traffic and see and 'station dump'

>  # iw dev wlan1 station dump
> Station e4:42:a6:24:c8:95 (on wlan1)
> 	inactive time:	0 ms
> 	rx bytes:	222415
> 	rx packets:	1678
> 	tx bytes:	8511140
> 	tx packets:	5828
> 	tx retries:	0
> 	tx failed:	4
> 	rx drop misc:	2
> 	signal:  	-39 [-54, -56, -39] dBm
> 	signal avg:	-39 [-53, -55, -39] dBm
> 	tx bitrate:	6.0 MBit/s
> 	rx bitrate:	360.0 MBit/s VHT-MCS 8 40MHz short GI VHT-NSS 2
> 	authorized:	yes
> 	authenticated:	yes
> 	associated:	yes
> 	preamble:	long
> 	WMM/WME:	yes
> 	MFP:		no
> 	TDLS peer:	no
> 	DTIM period:	2
> 	beacon interval:96
> 	short slot time:yes
> 	connected time:	1136 seconds
> 
> I see that ath10k does not implement ->dump_station callback, so which
> part of the code updates the generic "struct station_info" fields ?
> 
> Am I missing a patch ?
> 
Rate parameters are updated from below call,
.sta_statistics                 = ath10k_sta_statistics,

Thanks,
Anil.
Kalle Valo Dec. 1, 2017, 2:49 p.m. UTC | #8
Toke Høiland-Jørgensen <toke@toke.dk> writes:

> akolli@codeaurora.org writes:

>

>> On 2017-11-30 22:08, Kalle Valo wrote:

>>> Toke Høiland-Jørgensen <toke@toke.dk> writes:

>>> 

>>>>>> +struct ath10k_10_2_peer_tx_stats {

>>>>>> +	u8 ratecode[PEER_STATS_FOR_NO_OF_PPDUS];

>>>>>> +	u8 success_pkts[PEER_STATS_FOR_NO_OF_PPDUS];

>>>>>> +	__le16 success_bytes[PEER_STATS_FOR_NO_OF_PPDUS];

>>>>>> +	u8 retry_pkts[PEER_STATS_FOR_NO_OF_PPDUS];

>>>>>> +	__le16 retry_bytes[PEER_STATS_FOR_NO_OF_PPDUS];

>>>>>> +	u8 failed_pkts[PEER_STATS_FOR_NO_OF_PPDUS];

>>>>>> +	__le16 failed_bytes[PEER_STATS_FOR_NO_OF_PPDUS];

>>>>>> +	u8 flags[PEER_STATS_FOR_NO_OF_PPDUS];

>>>>>> +	__le32 tx_duration;

>>>>>> +	u8 tx_ppdu_cnt;

>>>>>> +	u8 peer_id;

>>>>>> +} __packed;

>>>>> 

>>>>> Toke, hopefully the tx_duration value here helps with ATF

>>>>> implementation

>>>>> using QCA988X.

>>>> 

>>>> Awesome! What's the semantics of this field? Just total

>>>> duration spent serving that station in the reporting interval?

>>>> Does it include retry attempts?

>>> 

>>> I have no clue :) I just noticed this while I was reviewing the patch

>>> internally and immediately recalled our discussions at Seoul. I can try

>>> to find out, but that will take a long time as I have way too much 

>>> stuff

>>> pending at the moment. Hopefully someone more knowledgeable 

>>> (Anilkumar?)

>>> can chime in and help.

>>

>> tx_duration is aggregate time duration of 4 PPDU sent to STA.

>> FW sends these values for retry packets also.

>

> Great, that sounds like just what we need.


Except mapping to the iee80211_tx_status() might be difficult. I'm not
sure how HTT_T2H_MSG_TYPE_PKTLOG events are sent in relation to
HTT_T2H_MSG_TYPE_TX_COMPL_IND.

-- 
Kalle Valo
Maxime Bizon Dec. 1, 2017, 3:05 p.m. UTC | #9
On Fri, 2017-12-01 at 19:18 +0530, akolli@codeaurora.org wrote:

> Hope CONFIG_MAC80211_DEBUGFS is enabled in your build.

it wasn't and IMHO it's confusing because tx rate is filled by the other
drivers without it.

I now have the following warning:

[   96.174967] ------------[ cut here ]------------
[   96.179640] WARNING: CPU: 0 PID: 609 at net/wireless/util.c:1254 cfg80211_calculate_bitrate+0x174/0x220
[   96.189538] invalid rate bw=1, mcs=9, nss=2
[   96.219736] CPU: 0 PID: 609 Comm: hostapd Not tainted 4.14.3-00381-gec9756b0f64d #28
[   96.227910] Hardware name: Marvell Kirkwood (Flattened Device Tree)
[   96.235450] [<80010124>] (unwind_backtrace) from [<8000d9ec>] (show_stack+0x10/0x14)
[   96.247180] [<8000d9ec>] (show_stack) from [<8002016c>] (__warn+0xdc/0xf8)
[   96.254243] [<8002016c>] (__warn) from [<800201bc>] (warn_slowpath_fmt+0x34/0x44)
[   96.262016] [<800201bc>] (warn_slowpath_fmt) from [<8064dfdc>] (cfg80211_calculate_bitrate+0x174/0x220)
[   96.272652] [<8064dfdc>] (cfg80211_calculate_bitrate) from [<806692d4>] (nl80211_put_sta_rate+0x44/0x1dc)
[   96.282509] [<806692d4>] (nl80211_put_sta_rate) from [<8066001c>] (nl80211_send_station+0x388/0xaf0)
[   96.292261] [<8066001c>] (nl80211_send_station) from [<8066082c>] (nl80211_get_station+0xa8/0xec)
[   96.304166] [<8066082c>] (nl80211_get_station) from [<80509c20>] (genl_rcv_msg+0x2dc/0x34c)
[   96.313324] [<80509c20>] (genl_rcv_msg) from [<8050890c>] (netlink_rcv_skb+0x84/0xdc)
[   96.321880] [<8050890c>] (netlink_rcv_skb) from [<805093c0>] (genl_rcv+0x20/0x34)
[   96.329668] [<805093c0>] (genl_rcv) from [<80508188>] (netlink_unicast+0x12c/0x1e0)
[   96.338408] [<80508188>] (netlink_unicast) from [<805085d8>] (netlink_sendmsg+0x2e0/0x304)
[   96.350736] [<805085d8>] (netlink_sendmsg) from [<804b5f9c>] (sock_sendmsg+0x14/0x24)
[   96.358656] [<804b5f9c>] (sock_sendmsg) from [<804b66e8>] (___sys_sendmsg+0x1c8/0x20c)
[   96.367093] [<804b66e8>] (___sys_sendmsg) from [<804b739c>] (__sys_sendmsg+0x40/0x64)
[   96.375276] [<804b739c>] (__sys_sendmsg) from [<8000a3e0>] (ret_fast_syscall+0x0/0x44)
[   96.383455] ---[ end trace da8257d6a850e91a ]---

# iw dev wlan1 station dump
Station e4:42:a6:24:c8:95 (on wlan1)
	inactive time:	550 ms
	rx bytes:	41217
	rx packets:	152
	tx bytes:	49397
	tx packets:	107
	tx retries:	0
	tx failed:	1
	rx drop misc:	0
	signal:  	-62 [-66, -65, -83] dBm
	signal avg:	-61 [-65, -65, -78] dBm
	tx bitrate:	 VHT-MCS 9 short GI VHT-NSS 2
	rx bitrate:	360.0 MBit/s VHT-MCS 8 40MHz short GI VHT-NSS 2
	rx duration:	0 us
	authorized:	yes
	authenticated:	yes
	associated:	yes
	preamble:	long
	WMM/WME:	yes
	MFP:		no
	TDLS peer:	no
	DTIM period:	2
	beacon interval:96
	short slot time:yes
	connected time:	5 seconds

Thanks
Toke Høiland-Jørgensen Dec. 1, 2017, 3:29 p.m. UTC | #10
Kalle Valo <kvalo@qca.qualcomm.com> writes:

>>> tx_duration is aggregate time duration of 4 PPDU sent to STA.
>>> FW sends these values for retry packets also.
>>
>> Great, that sounds like just what we need.
>
> Except mapping to the iee80211_tx_status() might be difficult. I'm not
> sure how HTT_T2H_MSG_TYPE_PKTLOG events are sent in relation to
> HTT_T2H_MSG_TYPE_TX_COMPL_IND.

Yeah, figures. Well, maybe we'll just have to support an asynchronous
callback into mac80211 to register airtime usage. Will probably have to
add some asynchronicity anyway to avoid doing too much work in the fast
path.

Will keep that in mind when I get around to revisiting those patches :)

-Toke
Kalle Valo Dec. 1, 2017, 3:44 p.m. UTC | #11
akolli@codeaurora.org writes:

>>> Parse peer stats from pktlog packets and update the tx rate
>>> information
>>> per STA. This way user space can query about transmit rate with iw:
>>
>> everything works ok, ath10k_update_per_peer_tx_stats() is called and
>> ath10k_sta fields are updated correctly
>>
>> but tx bitrate is still 6 MBit/s in station dump
>>
> Hope CONFIG_MAC80211_DEBUGFS is enabled in your build.
> Please Run ping traffic and see and 'station dump'

This feature should not depend on debugfs. Why is it needed? In patch 1
you already moved pktlog_filter to struct ath10k, does it need something
else as well?
Johannes Berg Dec. 1, 2017, 3:45 p.m. UTC | #12
On Fri, 2017-12-01 at 16:29 +0100, Toke Høiland-Jørgensen wrote:
> 
> Yeah, figures. Well, maybe we'll just have to support an asynchronous
> callback into mac80211 to register airtime usage. Will probably have to
> add some asynchronicity anyway to avoid doing too much work in the fast
> path.

I really think we should have that anyway. In fact, perhaps we should
just enforce it that way? Then ath9k would have to do a bit more work,
but it's also the slower of the devices :-)

But this plays in with the whole multi-queue RX we discussed before.

johannes
Christian Lamparter Dec. 1, 2017, 3:53 p.m. UTC | #13
On Friday, December 1, 2017 4:05:10 PM CET Maxime Bizon wrote:
> 
> On Fri, 2017-12-01 at 19:18 +0530, akolli@codeaurora.org wrote:
> 
> > Hope CONFIG_MAC80211_DEBUGFS is enabled in your build.
> 
> it wasn't and IMHO it's confusing because tx rate is filled by the other
> drivers without it.
> 
> I now have the following warning:
> 
> [   96.174967] ------------[ cut here ]------------
> [   96.179640] WARNING: CPU: 0 PID: 609 at net/wireless/util.c:1254 cfg80211_calculate_bitrate+0x174/0x220
> [   96.189538] invalid rate bw=1, mcs=9, nss=2
> [   96.219736] CPU: 0 PID: 609 Comm: hostapd Not tainted 4.14.3-00381-gec9756b0f64d #28
> [   96.227910] Hardware name: Marvell Kirkwood (Flattened Device Tree)
> [   96.235450] [<80010124>] (unwind_backtrace) from [<8000d9ec>] (show_stack+0x10/0x14)
> [   96.247180] [<8000d9ec>] (show_stack) from [<8002016c>] (__warn+0xdc/0xf8)
> [   96.254243] [<8002016c>] (__warn) from [<800201bc>] (warn_slowpath_fmt+0x34/0x44)
> [   96.262016] [<800201bc>] (warn_slowpath_fmt) from [<8064dfdc>] (cfg80211_calculate_bitrate+0x174/0x220)
> [   96.272652] [<8064dfdc>] (cfg80211_calculate_bitrate) from [<806692d4>] (nl80211_put_sta_rate+0x44/0x1dc)
> [   96.282509] [<806692d4>] (nl80211_put_sta_rate) from [<8066001c>] (nl80211_send_station+0x388/0xaf0)
> [   96.292261] [<8066001c>] (nl80211_send_station) from [<8066082c>] (nl80211_get_station+0xa8/0xec)
> [   96.304166] [<8066082c>] (nl80211_get_station) from [<80509c20>] (genl_rcv_msg+0x2dc/0x34c)
> [   96.313324] [<80509c20>] (genl_rcv_msg) from [<8050890c>] (netlink_rcv_skb+0x84/0xdc)
> [   96.321880] [<8050890c>] (netlink_rcv_skb) from [<805093c0>] (genl_rcv+0x20/0x34)
> [   96.329668] [<805093c0>] (genl_rcv) from [<80508188>] (netlink_unicast+0x12c/0x1e0)
> [   96.338408] [<80508188>] (netlink_unicast) from [<805085d8>] (netlink_sendmsg+0x2e0/0x304)
> [   96.350736] [<805085d8>] (netlink_sendmsg) from [<804b5f9c>] (sock_sendmsg+0x14/0x24)
> [   96.358656] [<804b5f9c>] (sock_sendmsg) from [<804b66e8>] (___sys_sendmsg+0x1c8/0x20c)
> [   96.367093] [<804b66e8>] (___sys_sendmsg) from [<804b739c>] (__sys_sendmsg+0x40/0x64)
> [   96.375276] [<804b739c>] (__sys_sendmsg) from [<8000a3e0>] (ret_fast_syscall+0x0/0x44)
> [   96.383455] ---[ end trace da8257d6a850e91a ]---
> 
Look for:

"[PATCH] ath10k: fix recent bandwidth conversion bug"
Toke Høiland-Jørgensen Dec. 1, 2017, 3:54 p.m. UTC | #14
Johannes Berg <johannes@sipsolutions.net> writes:

> On Fri, 2017-12-01 at 16:29 +0100, Toke Høiland-Jørgensen wrote:
>> 
>> Yeah, figures. Well, maybe we'll just have to support an asynchronous
>> callback into mac80211 to register airtime usage. Will probably have to
>> add some asynchronicity anyway to avoid doing too much work in the fast
>> path.
>
> I really think we should have that anyway. In fact, perhaps we should
> just enforce it that way? Then ath9k would have to do a bit more work,
> but it's also the slower of the devices :-)
>
> But this plays in with the whole multi-queue RX we discussed before.

Yeah, that's what I meant by 'add some asynchronicity anyway' :)

I guess that once we have an asynchronous scheduler task of some kind,
supporting the callback is easy, but pulling the data out of each packet
needs more work. But since we'll have to do that for ath9k anyway it
becomes more a question of whether it's something that should be
supported in mac80211 or if it should be implemented in each driver.
But since that logic will have to be written from scratch anyway, is
there any reason to not just do it in mac80211 from the beginning?

-Toke
Johannes Berg Dec. 1, 2017, 3:58 p.m. UTC | #15
On Fri, 2017-12-01 at 16:54 +0100, Toke Høiland-Jørgensen wrote:

> I guess that once we have an asynchronous scheduler task of some kind,
> supporting the callback is easy, but pulling the data out of each packet
> needs more work.

Right.


> But since we'll have to do that for ath9k anyway it
> becomes more a question of whether it's something that should be
> supported in mac80211 or if it should be implemented in each driver.
> But since that logic will have to be written from scratch anyway, is
> there any reason to not just do it in mac80211 from the beginning?

I was thinking in the driver so that there's no overhead for the other
drivers that don't want it that way.

Dunno. It probably doesn't really matter.

johannes
Maxime Bizon Dec. 1, 2017, 4:09 p.m. UTC | #16
On Fri, 2017-12-01 at 16:53 +0100, Christian Lamparter wrote:

> "[PATCH] ath10k: fix recent bandwidth conversion bug"

indeed, much better

thanks
Toke Høiland-Jørgensen Dec. 2, 2017, 9:53 a.m. UTC | #17
Johannes Berg <johannes@sipsolutions.net> writes:

> On Fri, 2017-12-01 at 16:54 +0100, Toke Høiland-Jørgensen wrote:
>
>> But since we'll have to do that for ath9k anyway it
>> becomes more a question of whether it's something that should be
>> supported in mac80211 or if it should be implemented in each driver.
>> But since that logic will have to be written from scratch anyway, is
>> there any reason to not just do it in mac80211 from the beginning?
>
> I was thinking in the driver so that there's no overhead for the other
> drivers that don't want it that way.
>
> Dunno. It probably doesn't really matter.

I'll prototype something, then we can revisit this based on actual code :)

-Toke
Anilkumar Kolli Dec. 4, 2017, 11:20 a.m. UTC | #18
> 
>>>> Parse peer stats from pktlog packets and update the tx rate
>>>> information
>>>> per STA. This way user space can query about transmit rate with iw:
>>> 
>>> everything works ok, ath10k_update_per_peer_tx_stats() is called and
>>> ath10k_sta fields are updated correctly
>>> 
>>> but tx bitrate is still 6 MBit/s in station dump
>>> 
>> Hope CONFIG_MAC80211_DEBUGFS is enabled in your build.
>> Please Run ping traffic and see and 'station dump'
> 
> This feature should not depend on debugfs. Why is it needed? In patch 1
> you already moved pktlog_filter to struct ath10k, does it need 
> something
> else as well?

ATH10K updates tx rate from this callback,
.sta_statistics                 = ath10k_sta_statistics,

This callback is defined under CONFIG_MAC80211_DEBUGFS.

Thanks,
Anil.
Anilkumar Kolli Dec. 4, 2017, 1:24 p.m. UTC | #19
On 2017-12-01 20:35, Maxime Bizon wrote:
> On Fri, 2017-12-01 at 19:18 +0530, akolli@codeaurora.org wrote:
> 
>> Hope CONFIG_MAC80211_DEBUGFS is enabled in your build.
> 
> it wasn't and IMHO it's confusing because tx rate is filled by the 
> other
> drivers without it.
> 
> I now have the following warning:
> 
> [   96.174967] ------------[ cut here ]------------
> [   96.179640] WARNING: CPU: 0 PID: 609 at net/wireless/util.c:1254
> cfg80211_calculate_bitrate+0x174/0x220
> [   96.189538] invalid rate bw=1, mcs=9, nss=2
> [   96.219736] CPU: 0 PID: 609 Comm: hostapd Not tainted
> 4.14.3-00381-gec9756b0f64d #28
> [   96.227910] Hardware name: Marvell Kirkwood (Flattened Device Tree)
> [   96.235450] [<80010124>] (unwind_backtrace) from [<8000d9ec>]
> (show_stack+0x10/0x14)
> [   96.247180] [<8000d9ec>] (show_stack) from [<8002016c>] 
> (__warn+0xdc/0xf8)
> [   96.254243] [<8002016c>] (__warn) from [<800201bc>]
> (warn_slowpath_fmt+0x34/0x44)
> [   96.262016] [<800201bc>] (warn_slowpath_fmt) from [<8064dfdc>]
> (cfg80211_calculate_bitrate+0x174/0x220)
> [   96.272652] [<8064dfdc>] (cfg80211_calculate_bitrate) from
> [<806692d4>] (nl80211_put_sta_rate+0x44/0x1dc)
> [   96.282509] [<806692d4>] (nl80211_put_sta_rate) from [<8066001c>]
> (nl80211_send_station+0x388/0xaf0)
> [   96.292261] [<8066001c>] (nl80211_send_station) from [<8066082c>]
> (nl80211_get_station+0xa8/0xec)
> [   96.304166] [<8066082c>] (nl80211_get_station) from [<80509c20>]
> (genl_rcv_msg+0x2dc/0x34c)
> [   96.313324] [<80509c20>] (genl_rcv_msg) from [<8050890c>]
> (netlink_rcv_skb+0x84/0xdc)
> [   96.321880] [<8050890c>] (netlink_rcv_skb) from [<805093c0>]
> (genl_rcv+0x20/0x34)
> [   96.329668] [<805093c0>] (genl_rcv) from [<80508188>]
> (netlink_unicast+0x12c/0x1e0)
> [   96.338408] [<80508188>] (netlink_unicast) from [<805085d8>]
> (netlink_sendmsg+0x2e0/0x304)
> [   96.350736] [<805085d8>] (netlink_sendmsg) from [<804b5f9c>]
> (sock_sendmsg+0x14/0x24)
> [   96.358656] [<804b5f9c>] (sock_sendmsg) from [<804b66e8>]
> (___sys_sendmsg+0x1c8/0x20c)
> [   96.367093] [<804b66e8>] (___sys_sendmsg) from [<804b739c>]
> (__sys_sendmsg+0x40/0x64)
> [   96.375276] [<804b739c>] (__sys_sendmsg) from [<8000a3e0>]
> (ret_fast_syscall+0x0/0x44)
> [   96.383455] ---[ end trace da8257d6a850e91a ]---
> 
> # iw dev wlan1 station dump
> Station e4:42:a6:24:c8:95 (on wlan1)
> 	inactive time:	550 ms
> 	rx bytes:	41217
> 	rx packets:	152
> 	tx bytes:	49397
> 	tx packets:	107
> 	tx retries:	0
> 	tx failed:	1
> 	rx drop misc:	0
> 	signal:  	-62 [-66, -65, -83] dBm
> 	signal avg:	-61 [-65, -65, -78] dBm
> 	tx bitrate:	 VHT-MCS 9 short GI VHT-NSS 2
> 	rx bitrate:	360.0 MBit/s VHT-MCS 8 40MHz short GI VHT-NSS 2
> 	rx duration:	0 us
> 	authorized:	yes
> 	authenticated:	yes
> 	associated:	yes
> 	preamble:	long
> 	WMM/WME:	yes
> 	MFP:		no
> 	TDLS peer:	no
> 	DTIM period:	2
> 	beacon interval:96
> 	short slot time:yes
> 	connected time:	5 seconds
> 
> Thanks

Hope 10.2.4-1.0-00029 Firmware binary works for you.
I will check this warning.

Thanks,
Anil.
Maxime Bizon Dec. 4, 2017, 2:23 p.m. UTC | #20
On Mon, 2017-12-04 at 18:54 +0530, akolli@codeaurora.org wrote:

> Hope 10.2.4-1.0-00029 Firmware binary works for you.

it does

> I will check this warning.

fixed by applying patch:
 "[PATCH] ath10k: fix recent bandwidth conversion bug"

as suggested by Christian Lamparter

only remaining oddity is the CONFIG_MAC80211_DEBUGFS dependency
Anilkumar Kolli Dec. 5, 2017, 5:26 a.m. UTC | #21
On 2017-12-04 19:53, Maxime Bizon wrote:
> On Mon, 2017-12-04 at 18:54 +0530, akolli@codeaurora.org wrote:
> 
>> Hope 10.2.4-1.0-00029 Firmware binary works for you.
> 
> it does
> 
>> I will check this warning.
> 
> fixed by applying patch:
>  "[PATCH] ath10k: fix recent bandwidth conversion bug"
> 
> as suggested by Christian Lamparter
> 
> only remaining oddity is the CONFIG_MAC80211_DEBUGFS dependency

I will send a patch to remove this dependency.

Thanks,
Anil.
diff mbox

Patch

diff --git a/drivers/net/wireless/ath/ath10k/debug.h b/drivers/net/wireless/ath/ath10k/debug.h
index 548ad5483a4a..290979ef4915 100644
--- a/drivers/net/wireless/ath/ath10k/debug.h
+++ b/drivers/net/wireless/ath/ath10k/debug.h
@@ -51,7 +51,8 @@  enum ath10k_pktlog_filter {
 	ATH10K_PKTLOG_RCFIND     = 0x000000004,
 	ATH10K_PKTLOG_RCUPDATE   = 0x000000008,
 	ATH10K_PKTLOG_DBG_PRINT  = 0x000000010,
-	ATH10K_PKTLOG_ANY        = 0x00000001f,
+	ATH10K_PKTLOG_PEER_STATS = 0x000000040,
+	ATH10K_PKTLOG_ANY        = 0x00000005f,
 };
 
 enum ath10k_dbg_aggr_mode {
@@ -60,6 +61,21 @@  enum ath10k_dbg_aggr_mode {
 	ATH10K_DBG_AGGR_MODE_MAX,
 };
 
+/* Types of packet log events */
+enum ath_pktlog_type {
+	ATH_PKTLOG_TYPE_TX_CTRL = 1,
+	ATH_PKTLOG_TYPE_TX_STAT,
+};
+
+struct ath10k_pktlog_hdr {
+	__le16 flags;
+	__le16 missed_cnt;
+	__le16 log_type; /* Type of log information foll this header */
+	__le16 size; /* Size of variable length log information in bytes */
+	__le32 timestamp;
+	u8 payload[0];
+} __packed;
+
 /* FIXME: How to calculate the buffer size sanely? */
 #define ATH10K_FW_STATS_BUF_SIZE (1024 * 1024)
 
diff --git a/drivers/net/wireless/ath/ath10k/htt.h b/drivers/net/wireless/ath/ath10k/htt.h
index 6305308422c4..89db96afea17 100644
--- a/drivers/net/wireless/ath/ath10k/htt.h
+++ b/drivers/net/wireless/ath/ath10k/htt.h
@@ -1497,6 +1497,23 @@  struct htt_peer_tx_stats {
 	u8 payload[0];
 } __packed;
 
+#define ATH10K_10_2_TX_STATS_OFFSET	136
+#define PEER_STATS_FOR_NO_OF_PPDUS	4
+
+struct ath10k_10_2_peer_tx_stats {
+	u8 ratecode[PEER_STATS_FOR_NO_OF_PPDUS];
+	u8 success_pkts[PEER_STATS_FOR_NO_OF_PPDUS];
+	__le16 success_bytes[PEER_STATS_FOR_NO_OF_PPDUS];
+	u8 retry_pkts[PEER_STATS_FOR_NO_OF_PPDUS];
+	__le16 retry_bytes[PEER_STATS_FOR_NO_OF_PPDUS];
+	u8 failed_pkts[PEER_STATS_FOR_NO_OF_PPDUS];
+	__le16 failed_bytes[PEER_STATS_FOR_NO_OF_PPDUS];
+	u8 flags[PEER_STATS_FOR_NO_OF_PPDUS];
+	__le32 tx_duration;
+	u8 tx_ppdu_cnt;
+	u8 peer_id;
+} __packed;
+
 union htt_rx_pn_t {
 	/* WEP: 24-bit PN */
 	u32 pn24;
diff --git a/drivers/net/wireless/ath/ath10k/htt_rx.c b/drivers/net/wireless/ath/ath10k/htt_rx.c
index e31438541ee1..3361807b87b3 100644
--- a/drivers/net/wireless/ath/ath10k/htt_rx.c
+++ b/drivers/net/wireless/ath/ath10k/htt_rx.c
@@ -2424,6 +2424,62 @@  static void ath10k_htt_fetch_peer_stats(struct ath10k *ar,
 	rcu_read_unlock();
 }
 
+static void ath10k_fetch_10_2_tx_stats(struct ath10k *ar, u8 *data)
+{
+	struct ath10k_pktlog_hdr *hdr = (struct ath10k_pktlog_hdr *)data;
+	struct ath10k_per_peer_tx_stats *p_tx_stats = &ar->peer_tx_stats;
+	struct ath10k_10_2_peer_tx_stats *tx_stats;
+	struct ieee80211_sta *sta;
+	struct ath10k_peer *peer;
+	u16 log_type = __le16_to_cpu(hdr->log_type);
+	u32 peer_id = 0, i;
+
+	if (log_type != ATH_PKTLOG_TYPE_TX_STAT)
+		return;
+
+	tx_stats = (struct ath10k_10_2_peer_tx_stats *)((hdr->payload) +
+		    ATH10K_10_2_TX_STATS_OFFSET);
+
+	if (!tx_stats->tx_ppdu_cnt)
+		return;
+
+	peer_id = tx_stats->peer_id;
+
+	rcu_read_lock();
+	spin_lock_bh(&ar->data_lock);
+	peer = ath10k_peer_find_by_id(ar, peer_id);
+	if (!peer) {
+		ath10k_warn(ar, "Invalid peer id %d in peer stats buffer\n",
+			    peer_id);
+		goto out;
+	}
+
+	sta = peer->sta;
+	for (i = 0; i < tx_stats->tx_ppdu_cnt; i++) {
+		p_tx_stats->succ_bytes =
+			__le16_to_cpu(tx_stats->success_bytes[i]);
+		p_tx_stats->retry_bytes =
+			__le16_to_cpu(tx_stats->retry_bytes[i]);
+		p_tx_stats->failed_bytes =
+			__le16_to_cpu(tx_stats->failed_bytes[i]);
+		p_tx_stats->ratecode = tx_stats->ratecode[i];
+		p_tx_stats->flags = tx_stats->flags[i];
+		p_tx_stats->succ_pkts = tx_stats->success_pkts[i];
+		p_tx_stats->retry_pkts = tx_stats->retry_pkts[i];
+		p_tx_stats->failed_pkts = tx_stats->failed_pkts[i];
+
+		ath10k_update_per_peer_tx_stats(ar, sta, p_tx_stats);
+	}
+	spin_unlock_bh(&ar->data_lock);
+	rcu_read_unlock();
+
+	return;
+
+out:
+	spin_unlock_bh(&ar->data_lock);
+	rcu_read_unlock();
+}
+
 bool ath10k_htt_t2h_msg_handler(struct ath10k *ar, struct sk_buff *skb)
 {
 	struct ath10k_htt *htt = &ar->htt;
@@ -2541,6 +2597,10 @@  bool ath10k_htt_t2h_msg_handler(struct ath10k *ar, struct sk_buff *skb)
 					skb->len -
 					offsetof(struct htt_resp,
 						 pktlog_msg.payload));
+
+		if (ath10k_peer_stats_enabled(ar))
+			ath10k_fetch_10_2_tx_stats(ar,
+						   resp->pktlog_msg.payload);
 		break;
 	}
 	case HTT_T2H_MSG_TYPE_RX_FLUSH: {
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 0a947eef348d..39a5408a1ce2 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -7536,6 +7536,16 @@  struct ath10k_mac_change_chanctx_arg {
 				    arvif->vdev_id, ret);
 	}
 
+	if (ath10k_peer_stats_enabled(ar)) {
+		ar->pktlog_filter |= ATH10K_PKTLOG_PEER_STATS;
+		ret = ath10k_wmi_pdev_pktlog_enable(ar,
+						    ar->pktlog_filter);
+		if (ret) {
+			ath10k_warn(ar, "failed to enable pktlog %d\n", ret);
+			goto err_stop;
+		}
+	}
+
 	mutex_unlock(&ar->conf_mutex);
 	return 0;