From: Kalle Valo <kvalo@kernel.org>
To: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Cc: Edmond Gagnon <egagnon@squareup.com>,
Benjamin Li <benl@squareup.com>,
"David S. Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>,
wcn36xx@lists.infradead.org, linux-wireless@vger.kernel.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 2/2] wcn36xx: Implement tx_rate reporting
Date: Sun, 20 Mar 2022 21:15:25 +0200 [thread overview]
Message-ID: <87pmmgo2pe.fsf@kernel.org> (raw)
In-Reply-To: <cda7eaa6-fb99-0d32-24fb-758b9363ee6d@linaro.org> (Bryan O'Donoghue's message of "Sun, 20 Mar 2022 18:03:10 +0000")
Bryan O'Donoghue <bryan.odonoghue@linaro.org> writes:
> On 20/03/2022 13:21, Bryan O'Donoghue wrote:
>> On 18/03/2022 19:58, Edmond Gagnon wrote:
>>> + INIT_DELAYED_WORK(&wcn->get_stats_work, wcn36xx_get_stats_work);
>>
>> Instead of forking a worker and polling we could add the relevant
>> SMD command to
>>
>> static int wcn36xx_smd_tx_compl_ind(struct wcn36xx *wcn, void *buf,
>> size_t len)
>> {
>> wcn36xx_smd_get_stats(wcn, 0xSomeMask);
>> }
>>
>> That way we only ever ask for and report a new TX data rate when we
>> know a TX event - and hence a potential TX data-rate update - has
>> taken place.
>>
>> ---
>> bod
>>
>
> Thinking a bit more
>
> - Do the SMD get_stats in the tx completion
> This might be a problem initiating another SMD transaction inside
> of an SMD callback. But is the most straight forward way to
> get the data while avoiding alot of needless polling.
>
> - Schedule your worker from the TX completion
> Again you should only care about gathering the data when you know
> something has happened which necessitates gathering that data
> like TX completion
>
> - Schedule your worker from the RX indication routine
> Seems not as logical as the first two but it might be easier
> to schedule the worker in the RX data handler
>
> Either way, I do think you should only gather this data on an event,
> not as a continuous poll.
I agree, a continuous poll is not a good idea as it affects power
consumption. What about struct ieee80211_ops::sta_statistics? AFAIK
that's called only when user space is requestings stats so the overhead
should be minimal.
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
next prev parent reply other threads:[~2022-03-20 19:15 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-18 19:58 [PATCH v2 0/2] wcn36xx: Implement tx_rate reporting Edmond Gagnon
2022-03-18 19:58 ` [PATCH v2 1/2] wcn36xx: Expose get_sta_index in wcn36xx.h Edmond Gagnon
2022-03-18 19:58 ` [PATCH v2 2/2] wcn36xx: Implement tx_rate reporting Edmond Gagnon
2022-03-18 23:23 ` kernel test robot
2022-03-20 13:21 ` Bryan O'Donoghue
2022-03-20 18:03 ` Bryan O'Donoghue
2022-03-20 19:15 ` Kalle Valo [this message]
2022-03-20 19:17 ` Kalle Valo
2022-03-23 21:45 ` [PATCH v3] " Edmond Gagnon
2022-03-23 21:55 ` Benjamin Li
2022-03-24 12:42 ` Bryan O'Donoghue
2022-03-24 14:41 ` Bryan O'Donoghue
2022-03-25 22:42 ` [PATCH v4] " Edmond Gagnon
2022-03-26 0:09 ` Jeff Johnson
2022-03-26 8:50 ` Kalle Valo
2022-03-30 8:04 ` Kalle Valo
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=87pmmgo2pe.fsf@kernel.org \
--to=kvalo@kernel.org \
--cc=benl@squareup.com \
--cc=bryan.odonoghue@linaro.org \
--cc=davem@davemloft.net \
--cc=egagnon@squareup.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=wcn36xx@lists.infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).