From: Anilkumar Kolli <akolli@codeaurora.org>
To: "Toke Høiland-Jørgensen" <toke@toke.dk>
Cc: linux-wireless-owner@vger.kernel.org,
Johannes Berg <johannes@sipsolutions.net>,
linux-wireless@vger.kernel.org, ath10k@lists.infradead.org,
Kalle Valo <kvalo@codeaurora.org>
Subject: Re: [RFC v2] ath10k: report tx rate using ieee80211_tx_status()
Date: Mon, 03 Sep 2018 15:49:32 +0530 [thread overview]
Message-ID: <01897c3dab4aa7c2371ef6791487413b@codeaurora.org> (raw)
In-Reply-To: <87r2ia28ii.fsf@toke.dk>
On 2018-09-03 15:43, Toke Høiland-Jørgensen wrote:
> Anilkumar Kolli <akolli@codeaurora.org> writes:
>
>> On 2018-08-31 19:52, Toke Høiland-Jørgensen wrote:
>>> Kalle Valo <kvalo@codeaurora.org> writes:
>>>
>>>> Anilkumar Kolli <akolli@codeaurora.org> writes:
>>>>
>>>>> Mesh path metric needs txrate information from
>>>>> ieee80211_tx_status()
>>>>> call but in ath10k there is no mechanism to report tx rate
>>>>> information
>>>>> via ieee80211_tx_status(), the rate is only accessible via
>>>>> sta_statiscs() op.
>>>>>
>>>>> Per peer stats has tx rate info available, this patch stores per
>>>>> peer
>>>>> last tx rate and updates the tx rate info structures in tx
>>>>> completition.
>>>>> The rate updated in ieee80211_tx_status() is not exactly for the
>>>>> last
>>>>> transmitted frame instead the rate is from one of the previous
>>>>> frames.
>>>>>
>>>>> Per peer txrate information is updated through per peer statistics
>>>>> and is available for QCA9888/QCA9984/QCA4019/QCA998X only
>>>>>
>>>>> Tested on QCA9984 with firmware-5.bin_10.4-3.5.3-00053
>>>>> Tested on QCA998X with firmware-5.bin_10.2.4-1.0-00036
>>>>>
>>>>> Signed-off-by: Anilkumar Kolli <akolli@codeaurora.org>
>>>>
>>>> This is a patch from last March, full patch here:
>>>>
>>>> https://patchwork.kernel.org/patch/10267693/
>>>>
>>>>> @@ -119,6 +122,18 @@ int ath10k_txrx_tx_unref(struct ath10k_htt
>>>>> *htt,
>>>>> info->flags &= ~IEEE80211_TX_STAT_ACK;
>>>>> }
>>>>>
>>>>> + if (sta) {
>>>>> + spin_lock_bh(&ar->data_lock);
>>>>> + arsta = (struct ath10k_sta *)sta->drv_priv;
>>>>> + info->status.rates[0].idx =
>>>>> + arsta->tx_info.status.rates[0].idx;
>>>>> + info->status.rates[0].count =
>>>>> + arsta->tx_info.status.rates[0].count;
>>>>> + info->status.rates[0].flags =
>>>> <> + arsta->tx_info.status.rates[0].flags;
>>>>> + spin_unlock_bh(&ar->data_lock);
>>>>> + }
>>>>> +
>>>>> ieee80211_tx_status(htt->ar->hw, msdu);
>>>>> /* we do not own the msdu anymore */
>>>>
>>>> "is not exactly" is IMHO an understatement. What it means that with
>>>> this
>>>> patch ath10k reports the rate information from another frame instead
>>>> of
>>>> the current skb, because the firmware provides the rate information
>>>> "out
>>>> of band". A simple example to clarify:
>>>>
>>>> Let's say ath10k transmits frames A, B and C. Then ath10k calls
>>>> ieee80211_tx_status() for frame C the rate information could be
>>>> for
>>>> frame A, or it could be the other around for frame A status the
>>>> rate
>>>> information is from frame C.
>>>>
>>>> In other words, there's no guarantee from what frame the rate
>>>> information is from.
>>>>
>>>> Too me this feels like a bad idea but I'm not familiar enough with
>>>> mac80211 to really comment on this. What kind of implications does
>>>> this
>>>> have for Mesh or ATF, for example? Adding Johannes and Toke to hear
>>>> about their opinion about this.
>>>
>>> I was under the impression that the values gathered (at least for
>>> airtime) would be cumulative values? If it's just the airtime of a
>>> single random frame, which is what I understand from your example,
>>> it's
>>> not going to be terribly useful to provide ATF at least...
>>>
>>> -Toke
>>
>> The design:
>> Whenever radio transmits packet, firmware will record numbers of bytes
>> sent, MSDU’s sent, TX duration, AMPDU information, ACK fail, BA fail,
>> Rate at which packet is sent. This is recorded for 4 frames sent on
>> that
>> peer. Once 4 frames are sent for that peer, TX packet event is sent to
>> ath10k driver with the recorded values. These rate values are updated
>> to
>> mac80211 using ieee80211_tx_status().
>
> So the values reported are the sums for all four packets? But the
> latest
> value for rate information?
>
> -Toke
Tx rate is updated for the 4th packet.
Thanks
Anil.
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
WARNING: multiple messages have this Message-ID (diff)
From: Anilkumar Kolli <akolli@codeaurora.org>
To: "Toke Høiland-Jørgensen" <toke@toke.dk>
Cc: Kalle Valo <kvalo@codeaurora.org>,
ath10k@lists.infradead.org, linux-wireless@vger.kernel.org,
Johannes Berg <johannes@sipsolutions.net>,
linux-wireless-owner@vger.kernel.org
Subject: Re: [RFC v2] ath10k: report tx rate using ieee80211_tx_status()
Date: Mon, 03 Sep 2018 15:49:32 +0530 [thread overview]
Message-ID: <01897c3dab4aa7c2371ef6791487413b@codeaurora.org> (raw)
In-Reply-To: <87r2ia28ii.fsf@toke.dk>
On 2018-09-03 15:43, Toke Høiland-Jørgensen wrote:
> Anilkumar Kolli <akolli@codeaurora.org> writes:
>
>> On 2018-08-31 19:52, Toke Høiland-Jørgensen wrote:
>>> Kalle Valo <kvalo@codeaurora.org> writes:
>>>
>>>> Anilkumar Kolli <akolli@codeaurora.org> writes:
>>>>
>>>>> Mesh path metric needs txrate information from
>>>>> ieee80211_tx_status()
>>>>> call but in ath10k there is no mechanism to report tx rate
>>>>> information
>>>>> via ieee80211_tx_status(), the rate is only accessible via
>>>>> sta_statiscs() op.
>>>>>
>>>>> Per peer stats has tx rate info available, this patch stores per
>>>>> peer
>>>>> last tx rate and updates the tx rate info structures in tx
>>>>> completition.
>>>>> The rate updated in ieee80211_tx_status() is not exactly for the
>>>>> last
>>>>> transmitted frame instead the rate is from one of the previous
>>>>> frames.
>>>>>
>>>>> Per peer txrate information is updated through per peer statistics
>>>>> and is available for QCA9888/QCA9984/QCA4019/QCA998X only
>>>>>
>>>>> Tested on QCA9984 with firmware-5.bin_10.4-3.5.3-00053
>>>>> Tested on QCA998X with firmware-5.bin_10.2.4-1.0-00036
>>>>>
>>>>> Signed-off-by: Anilkumar Kolli <akolli@codeaurora.org>
>>>>
>>>> This is a patch from last March, full patch here:
>>>>
>>>> https://patchwork.kernel.org/patch/10267693/
>>>>
>>>>> @@ -119,6 +122,18 @@ int ath10k_txrx_tx_unref(struct ath10k_htt
>>>>> *htt,
>>>>> info->flags &= ~IEEE80211_TX_STAT_ACK;
>>>>> }
>>>>>
>>>>> + if (sta) {
>>>>> + spin_lock_bh(&ar->data_lock);
>>>>> + arsta = (struct ath10k_sta *)sta->drv_priv;
>>>>> + info->status.rates[0].idx =
>>>>> + arsta->tx_info.status.rates[0].idx;
>>>>> + info->status.rates[0].count =
>>>>> + arsta->tx_info.status.rates[0].count;
>>>>> + info->status.rates[0].flags =
>>>> <> + arsta->tx_info.status.rates[0].flags;
>>>>> + spin_unlock_bh(&ar->data_lock);
>>>>> + }
>>>>> +
>>>>> ieee80211_tx_status(htt->ar->hw, msdu);
>>>>> /* we do not own the msdu anymore */
>>>>
>>>> "is not exactly" is IMHO an understatement. What it means that with
>>>> this
>>>> patch ath10k reports the rate information from another frame instead
>>>> of
>>>> the current skb, because the firmware provides the rate information
>>>> "out
>>>> of band". A simple example to clarify:
>>>>
>>>> Let's say ath10k transmits frames A, B and C. Then ath10k calls
>>>> ieee80211_tx_status() for frame C the rate information could be
>>>> for
>>>> frame A, or it could be the other around for frame A status the
>>>> rate
>>>> information is from frame C.
>>>>
>>>> In other words, there's no guarantee from what frame the rate
>>>> information is from.
>>>>
>>>> Too me this feels like a bad idea but I'm not familiar enough with
>>>> mac80211 to really comment on this. What kind of implications does
>>>> this
>>>> have for Mesh or ATF, for example? Adding Johannes and Toke to hear
>>>> about their opinion about this.
>>>
>>> I was under the impression that the values gathered (at least for
>>> airtime) would be cumulative values? If it's just the airtime of a
>>> single random frame, which is what I understand from your example,
>>> it's
>>> not going to be terribly useful to provide ATF at least...
>>>
>>> -Toke
>>
>> The design:
>> Whenever radio transmits packet, firmware will record numbers of bytes
>> sent, MSDU’s sent, TX duration, AMPDU information, ACK fail, BA fail,
>> Rate at which packet is sent. This is recorded for 4 frames sent on
>> that
>> peer. Once 4 frames are sent for that peer, TX packet event is sent to
>> ath10k driver with the recorded values. These rate values are updated
>> to
>> mac80211 using ieee80211_tx_status().
>
> So the values reported are the sums for all four packets? But the
> latest
> value for rate information?
>
> -Toke
Tx rate is updated for the 4th packet.
Thanks
Anil.
next prev parent reply other threads:[~2018-09-03 10:19 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-21 6:23 [RFC v2] ath10k: report tx rate using ieee80211_tx_status() Anilkumar Kolli
2018-04-21 6:23 ` Anilkumar Kolli
2018-04-24 8:02 ` Kalle Valo
2018-04-24 8:02 ` Kalle Valo
2018-04-25 9:59 ` Anilkumar Kolli
2018-04-25 9:59 ` Anilkumar Kolli
2018-04-25 14:03 ` Kalle Valo
2018-04-25 14:03 ` Kalle Valo
2018-08-21 6:04 ` Anilkumar Kolli
2018-08-21 6:04 ` Anilkumar Kolli
2018-08-21 7:46 ` Kalle Valo
2018-08-21 7:46 ` Kalle Valo
2018-08-31 12:29 ` Kalle Valo
2018-08-31 12:29 ` Kalle Valo
2018-08-31 14:22 ` Toke Høiland-Jørgensen
2018-08-31 14:22 ` Toke Høiland-Jørgensen
2018-09-03 5:37 ` Anilkumar Kolli
2018-09-03 5:37 ` Anilkumar Kolli
2018-09-03 10:13 ` Toke Høiland-Jørgensen
2018-09-03 10:13 ` Toke Høiland-Jørgensen
2018-09-03 10:19 ` Anilkumar Kolli [this message]
2018-09-03 10:19 ` Anilkumar Kolli
2018-09-03 10:18 ` Johannes Berg
2018-09-03 10:18 ` Johannes Berg
2018-09-06 7:10 ` Anilkumar Kolli
2018-09-06 7:10 ` Anilkumar Kolli
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=01897c3dab4aa7c2371ef6791487413b@codeaurora.org \
--to=akolli@codeaurora.org \
--cc=ath10k@lists.infradead.org \
--cc=johannes@sipsolutions.net \
--cc=kvalo@codeaurora.org \
--cc=linux-wireless-owner@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=toke@toke.dk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.