From: Kalle Valo <kvalo@codeaurora.org>
To: Tony Chuang <yhchuang@realtek.com>
Cc: "linux-wireless\@vger.kernel.org"
<linux-wireless@vger.kernel.org>,
"briannorris\@chromium.org" <briannorris@chromium.org>,
"g.schlmm\@googlemail.com" <g.schlmm@googlemail.com>
Subject: Re: [PATCH 3/6] rtw88: use a module parameter to control LPS enter
Date: Fri, 01 Nov 2019 10:30:57 +0200 [thread overview]
Message-ID: <87imo40zi6.fsf@codeaurora.org> (raw)
In-Reply-To: <F7CD281DE3E379468C6D07993EA72F84D1914F4C@RTITMBSVM04.realtek.com.tw> (Tony Chuang's message of "Thu, 31 Oct 2019 08:17:37 +0000")
Tony Chuang <yhchuang@realtek.com> writes:
> From: Kalle Valo
>> <yhchuang@realtek.com> wrote:
>>
>> > From: Yan-Hsuan Chuang <yhchuang@realtek.com>
>> >
>> > If the number of packets is less than the LPS threshold, driver
>> > can then enter LPS mode.
>> > And driver used to take RTW_LPS_THRESHOLD as the threshold. As
>> > the macro can not be changed after compiled, use a parameter
>> > instead.
>> >
>> > The larger of the threshold, the more traffic required to leave
>> > power save mode, responsive time could be longer, but also the
>> > power consumption could be lower.
>> >
>> > Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
>> > Reviewed-by: Chris Chiu <chiu@endlessm.com>
>>
>> I don't think a module parameter should be used to control power save
>> level, instead there should be a generic interface for that. Also the commit
>> log does not give any explanation why this needs to be a module parameter.
>>
>> Tony, there's a high barrier for adding new module parameters. It's a
>> common
>> phrase for me to say "module parameters are not windows .ini files". And to
>> make it
>> easier for everyone always submit controversial patches separately, do not
>> hide
>> within a bigger patchset.
>>
>
> Alright, I was thinking module parameters as a convenient tool for driver to
> control the behavior for debugging or out-of-band adjusting. But it seems like
> you treat it more carefully.
>
> Actually this is just going to allow us to set different default values for different
> use cases. So is there a better way to control it. Or I should just change the
> value to a better one. By our experience, set this to 50 is a more reasonable
> value, such that some web surfing or background traffic wouldn't make the
> driver to leave PS mode.
I recall having a similar discussion something like 10 years ago. (Yes,
I have been here for way too long). I think at the time recommendation
was to use latency value from the QoS framework to make it possible for
user space to change wireless power save aggressiveness. But I don't
know if anyone really used that.
I was feeling nostalgic and decided to find some pointers:
https://lore.kernel.org/linux-wireless/1271850458-32437-2-git-send-email-juuso.oikarinen@nokia.com/
And it seems the patch was even applied:
195e294d21e8 mac80211: Determine dynamic PS timeout based on ps-qos network latency
This is for mac80211 dynamic ps feature, but I imagine we could somehow
extend it to driver settings like the LPS threshold here. Something like
this would be much more acceptable than having custom module parameters
for each driver.
--
Kalle Valo
next prev parent reply other threads:[~2019-11-01 8:31 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-25 9:33 [PATCH 0/6] rtw88: minor driver updates yhchuang
2019-10-25 9:33 ` [PATCH 1/6] rtw88: 8822b: add RFE type 3 support yhchuang
2019-10-31 8:04 ` Kalle Valo
2019-10-25 9:33 ` [PATCH 2/6] rtw88: use rtw_phy_pg_cfg_pair struct, not arrays yhchuang
2019-10-25 9:33 ` [PATCH 3/6] rtw88: use a module parameter to control LPS enter yhchuang
2019-10-25 10:51 ` Chris Chiu
2019-10-28 3:12 ` Tony Chuang
2019-10-29 4:01 ` Chris Chiu
2019-10-31 7:59 ` Kalle Valo
[not found] ` <20191031075911.3CCB86079C@smtp.codeaurora.org>
2019-10-31 8:17 ` Tony Chuang
2019-10-31 20:01 ` Brian Norris
2019-11-01 3:13 ` Tony Chuang
2019-11-01 8:35 ` Kalle Valo
2019-11-01 8:30 ` Kalle Valo [this message]
2019-10-25 9:33 ` [PATCH 4/6] rtw88: rearrange if..else statements for rx rate indexes yhchuang
2019-10-25 9:33 ` [PATCH 5/6] rtw88: fix potential read outside array boundary yhchuang
2019-10-25 9:33 ` [PATCH 6/6] rtw88: avoid FW info flood yhchuang
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=87imo40zi6.fsf@codeaurora.org \
--to=kvalo@codeaurora.org \
--cc=briannorris@chromium.org \
--cc=g.schlmm@googlemail.com \
--cc=linux-wireless@vger.kernel.org \
--cc=yhchuang@realtek.com \
/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).