From: Thiraviyam Mariyappan <tmariyap@codeaurora.org>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: ath11k@lists.infradead.org, linux-wireless@vger.kernel.org
Subject: Re: [PATCHv2] mac80211: increment rx stats according to USES_RSS flag
Date: Thu, 06 May 2021 23:19:06 +0530 [thread overview]
Message-ID: <df6e33fe198e179f1c1f31ca6d55e995@codeaurora.org> (raw)
In-Reply-To: <ec30381c062e3eb87abb724641a15331cfc3d11c.camel@sipsolutions.net>
On 2021-04-23 13:28, Johannes Berg wrote:
> On Wed, 2021-04-21 at 22:18 +0530, Thiraviyam Mariyappan wrote:
>> In case of Mesh fast_rx is not applicable, but still USES_RSS can be
>> enabled from driver when parallel RX is supported by HW/Driver,
>> right?
>
> Yes, I guess that's true.
>
>> Hence checked for USES_RSS support to update per cpu stats.Please
>> correct me if the meaning of USES_RSS is misunderstood and it applies
>> only when fast_rx for a STA is enabled.
>>
>
> Well, actually using multi-queue is pointless or even
> counter-productive
> when you don't have fast-RX, since then you'll run into a common lock,
> and doing much processing on multiple CPUs but under a common lock
> might
> well be worse than doing it on a single CPU in the first place, since
> you'll bounce the lock around all the time.
>
> However, you're right that the driver might generally advertise
> USES_RSS, but then not do it for mesh, but that throws off some
> statistics.
>
> Something like this might then be a much better fix though?
Below fix good to me and working fine.
>
>
> diff --git a/net/mac80211/sta_info.c b/net/mac80211/sta_info.c
> index ec6973ee88ef..f87e883862d9 100644
> --- a/net/mac80211/sta_info.c
> +++ b/net/mac80211/sta_info.c
> @@ -2092,7 +2092,7 @@ sta_get_last_rx_stats(struct sta_info *sta)
> struct ieee80211_local *local = sta->local;
> int cpu;
>
> - if (!ieee80211_hw_check(&local->hw, USES_RSS))
> + if (!sta->pcpu_rx_stats)
> return stats;
>
> for_each_possible_cpu(cpu) {
> @@ -2192,9 +2192,7 @@ static void sta_set_tidstats(struct sta_info
> *sta,
> int cpu;
>
> if (!(tidstats->filled & BIT(NL80211_TID_STATS_RX_MSDU))) {
> - if (!ieee80211_hw_check(&local->hw, USES_RSS))
> - tidstats->rx_msdu +=
> - sta_get_tidstats_msdu(&sta->rx_stats, tid);
> + tidstats->rx_msdu += sta_get_tidstats_msdu(&sta->rx_stats, tid);
>
> if (sta->pcpu_rx_stats) {
> for_each_possible_cpu(cpu) {
> @@ -2308,8 +2306,7 @@ void sta_set_sinfo(struct sta_info *sta, struct
> station_info *sinfo,
>
> if (!(sinfo->filled & (BIT_ULL(NL80211_STA_INFO_RX_BYTES64) |
> BIT_ULL(NL80211_STA_INFO_RX_BYTES)))) {
> - if (!ieee80211_hw_check(&local->hw, USES_RSS))
> - sinfo->rx_bytes += sta_get_stats_bytes(&sta->rx_stats);
> + sinfo->rx_bytes += sta_get_stats_bytes(&sta->rx_stats);
>
> if (sta->pcpu_rx_stats) {
> for_each_possible_cpu(cpu) {
>
>
> johannes
--
ath11k mailing list
ath11k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath11k
WARNING: multiple messages have this Message-ID (diff)
From: Thiraviyam Mariyappan <tmariyap@codeaurora.org>
To: Johannes Berg <johannes@sipsolutions.net>
Cc: ath11k@lists.infradead.org, linux-wireless@vger.kernel.org
Subject: Re: [PATCHv2] mac80211: increment rx stats according to USES_RSS flag
Date: Thu, 06 May 2021 23:19:06 +0530 [thread overview]
Message-ID: <df6e33fe198e179f1c1f31ca6d55e995@codeaurora.org> (raw)
In-Reply-To: <ec30381c062e3eb87abb724641a15331cfc3d11c.camel@sipsolutions.net>
On 2021-04-23 13:28, Johannes Berg wrote:
> On Wed, 2021-04-21 at 22:18 +0530, Thiraviyam Mariyappan wrote:
>> In case of Mesh fast_rx is not applicable, but still USES_RSS can be
>> enabled from driver when parallel RX is supported by HW/Driver,
>> right?
>
> Yes, I guess that's true.
>
>> Hence checked for USES_RSS support to update per cpu stats.Please
>> correct me if the meaning of USES_RSS is misunderstood and it applies
>> only when fast_rx for a STA is enabled.
>>
>
> Well, actually using multi-queue is pointless or even
> counter-productive
> when you don't have fast-RX, since then you'll run into a common lock,
> and doing much processing on multiple CPUs but under a common lock
> might
> well be worse than doing it on a single CPU in the first place, since
> you'll bounce the lock around all the time.
>
> However, you're right that the driver might generally advertise
> USES_RSS, but then not do it for mesh, but that throws off some
> statistics.
>
> Something like this might then be a much better fix though?
Below fix good to me and working fine.
>
>
> diff --git a/net/mac80211/sta_info.c b/net/mac80211/sta_info.c
> index ec6973ee88ef..f87e883862d9 100644
> --- a/net/mac80211/sta_info.c
> +++ b/net/mac80211/sta_info.c
> @@ -2092,7 +2092,7 @@ sta_get_last_rx_stats(struct sta_info *sta)
> struct ieee80211_local *local = sta->local;
> int cpu;
>
> - if (!ieee80211_hw_check(&local->hw, USES_RSS))
> + if (!sta->pcpu_rx_stats)
> return stats;
>
> for_each_possible_cpu(cpu) {
> @@ -2192,9 +2192,7 @@ static void sta_set_tidstats(struct sta_info
> *sta,
> int cpu;
>
> if (!(tidstats->filled & BIT(NL80211_TID_STATS_RX_MSDU))) {
> - if (!ieee80211_hw_check(&local->hw, USES_RSS))
> - tidstats->rx_msdu +=
> - sta_get_tidstats_msdu(&sta->rx_stats, tid);
> + tidstats->rx_msdu += sta_get_tidstats_msdu(&sta->rx_stats, tid);
>
> if (sta->pcpu_rx_stats) {
> for_each_possible_cpu(cpu) {
> @@ -2308,8 +2306,7 @@ void sta_set_sinfo(struct sta_info *sta, struct
> station_info *sinfo,
>
> if (!(sinfo->filled & (BIT_ULL(NL80211_STA_INFO_RX_BYTES64) |
> BIT_ULL(NL80211_STA_INFO_RX_BYTES)))) {
> - if (!ieee80211_hw_check(&local->hw, USES_RSS))
> - sinfo->rx_bytes += sta_get_stats_bytes(&sta->rx_stats);
> + sinfo->rx_bytes += sta_get_stats_bytes(&sta->rx_stats);
>
> if (sta->pcpu_rx_stats) {
> for_each_possible_cpu(cpu) {
>
>
> johannes
next prev parent reply other threads:[~2021-05-06 17:49 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-17 11:56 [PATCHv2] mac80211: increment rx stats according to USES_RSS flag Thiraviyam Mariyappan
2021-02-17 11:56 ` Thiraviyam Mariyappan
2021-04-08 9:39 ` Johannes Berg
2021-04-08 9:39 ` Johannes Berg
2021-04-08 10:01 ` Johannes Berg
2021-04-08 10:01 ` Johannes Berg
2021-04-21 16:48 ` Thiraviyam Mariyappan
2021-04-21 16:48 ` Thiraviyam Mariyappan
2021-04-23 7:58 ` Johannes Berg
2021-04-23 7:58 ` Johannes Berg
2021-05-06 17:49 ` Thiraviyam Mariyappan [this message]
2021-05-06 17:49 ` Thiraviyam Mariyappan
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=df6e33fe198e179f1c1f31ca6d55e995@codeaurora.org \
--to=tmariyap@codeaurora.org \
--cc=ath11k@lists.infradead.org \
--cc=johannes@sipsolutions.net \
--cc=linux-wireless@vger.kernel.org \
/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.