linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Kalle Valo <kvalo@codeaurora.org>
To: Tony Chuang <yhchuang@realtek.com>
Cc: Johannes Berg <johannes@sipsolutions.net>,
	"linux-wireless\@vger.kernel.org"
	<linux-wireless@vger.kernel.org>,
	"briannorris\@chromium.org" <briannorris@chromium.org>
Subject: Re: [PATCH] rtw88: add debugfs to fix tx rate
Date: Tue, 17 Mar 2020 17:40:58 +0200	[thread overview]
Message-ID: <875zf3kn05.fsf@kamboji.qca.qualcomm.com> (raw)
In-Reply-To: <ce990869ebf0478d98cd7e8416b36289@realtek.com> (Tony Chuang's message of "Tue, 17 Mar 2020 10:32:58 +0000")

Tony Chuang <yhchuang@realtek.com> writes:

> // Add Johannes for commenting on adding another nl80211 commands
>
> Kalle Valo <kvalo@codeaurora.org> writes:> 
>
>> Tony Chuang <yhchuang@realtek.com> writes:
>> 
>> > Kalle Valo <kvalo@codeaurora.org> writes:
>> >
>> >> <yhchuang@realtek.com> writes:
>> >>
>> >> > From: Yan-Hsuan Chuang <yhchuang@realtek.com>
>> >> >
>> >> > It is useful to fix the bit rate of TX packets. For example, if
>> >> > someone is measuring the TX power, or debugging with the issues
>> >> > of the TX throughput on the field.
>> >> >
>> >> > To set the value of fixed rate, one should input corresponding
>> >> > desc rate index (ex, 0x0b for DESC_RATE54M to fix at 54 Mbps).
>> >> > Set a value larger than DESC_RATE_MAX will disable fix rate, so
>> >> > the rate adaptive mechanism can resume to work.
>> >> >
>> >> > Example,
>> >> >   To fix rate at MCS 1:
>> >> >   echo 0x0d > /sys/kernel/debug/ieee80211/phy0/rtw88/fix_rate
>> >> >
>> >> >   To not to fix rate:
>> >> >   echo 0xff > /sys/kernel/debug/ieee80211/phy0/rtw88/fix_rate
>> >> >
>> >> >   To know which rate was fixed at:
>> >> >   cat /sys/kernel/debug/ieee80211/phy0/rtw88/fix_rate
>> >> >
>> >> > Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
>> >>
>> >> No way, debugfs is not a method for working around nl80211 and doing
>> >> whatever idea you come up with. The goal is that we have a generic
>> >> nl80211 command for all generic actions, like this one. And I think we
>> >> already have an nl80211 command for fixing the tx rate, right?
>> >>
>> >
>> > No, as I can see, there's no suitable nl80211 command that can achieve
>> > what I want. If you are saying about
>> NL80211_CMD_SET_TX_BITRATE_MASK,
>> > it's used to allow some rates. But actually the firmware has its own rate
>> > adaptive mechanism, so mask out the other rates does not mean the rate
>> > left will be chosen. Moreover, the hardware will choose a lower bit rate
>> > when retry, then the TX rate is not fixed at all. So the debugfs can disable
>> > the firmware's RA mechanism, also disable the TX rate fall back when retry.
>> > Both of them cannot be done by setting TX bitrate mask.
>> 
>> I'm confused, here you talk about firmware implementation etc but I'm
>> just talking about replacing the fix_rate debugfs file to an nl80211
>> command (for providing the fix_rate value). Can you clarify more why you
>> think nl80211 is not suitable?
>
> Oops, I thought that you wanted me to use the existing nl80211
> command.

Either use an existing nl80211 command or add a new one if needed. For
me most important is that we don't add hacks to debugfs just for
avoiding using nl80211.

> Now I know that you think we can add a new nl80211 command to help
> drivers to fix the TX bitrate if necessary. If adding another nl80211
> command for that is acceptable, I can work on this. But I need
> Johannes's comment if it's better to add a new nl80211 command or to
> expand the existing command (ex. NL80211_CMD_SET_TX_BITRATE_MASK).

_Why_ is NL80211_CMD_SET_TX_BITRATE_MASK not suitable for you? You keep
saying that but I have still figured out why exactly you think so.
Please clarify this in detail. 

> It looks like that adding a new nl80211 command will be better for me
> as expanding the existing one would have great impact on the already
> distributed drivers/user-tools.

What kind of great impact are you talking about? Please be specific so
that we don't need to guess.

-- 
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches

  reply	other threads:[~2020-03-17 15:41 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-13  6:51 [PATCH] rtw88: add debugfs to fix tx rate yhchuang
2020-03-13 10:33 ` Kalle Valo
2020-03-16  2:28   ` Tony Chuang
2020-03-17  7:10     ` Kalle Valo
2020-03-17 10:32       ` Tony Chuang
2020-03-17 15:40         ` Kalle Valo [this message]
2020-03-17 15:49           ` Ben Greear
2020-03-18  9:02             ` Tony Chuang
2020-03-20 13:05               ` Johannes Berg
2020-03-25  0:03                 ` Brian Norris
2020-03-25  2:55                   ` Tony Chuang
2020-03-25  5:16                     ` Brian Norris
2020-03-25  5:54                       ` Tony Chuang
2020-03-25  9:10                         ` Johannes Berg
2020-03-25 15:52                       ` Ben Greear
2020-03-25 18:14                         ` Brian Norris
2020-05-25  9:07                           ` Johannes Berg
2020-05-25 16:16                             ` Ben Greear
2020-03-26 18:27 ` Brian Norris
2021-11-26 16:19 ` Kalle Valo
2021-11-29  2:25   ` Pkshih

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=875zf3kn05.fsf@kamboji.qca.qualcomm.com \
    --to=kvalo@codeaurora.org \
    --cc=briannorris@chromium.org \
    --cc=johannes@sipsolutions.net \
    --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).