From: Ben Greear <greearb@candelatech.com>
To: Jonas Jelonek <jelonek.jonas@gmail.com>
Cc: "Thomas Hühn" <thomas@inet.tu-berlin.de>,
linux-wireless <linux-wireless@vger.kernel.org>,
"Kalle Valo" <kvalo@kernel.org>, "nbd@nbd.name" <nbd@nbd.name>,
johannes@sipsolutions.net
Subject: Re: [PATCH v2 1/2] mac80211: extend current rate control tx status API
Date: Thu, 10 Mar 2022 09:33:45 -0800 [thread overview]
Message-ID: <0a447b8e-647f-2f0e-4444-35792974e1e6@candelatech.com> (raw)
In-Reply-To: <CAChE-vRdnLgjGt3wDrzDC_eKWnX-wi_bWAiBYcheZrSMcfDoyQ@mail.gmail.com>
On 3/10/22 9:27 AM, Jonas Jelonek wrote:
> On 3/10/22 16:43 UTC, Ben Greear wrote:
>>>
>>> Certain 802.11a/g/n Atheros chips provide a 0,5dB tx-power step granularity, while Mediatek 802.11ac chips have 1dB or even 3dB step width. So I would argue that a 1dB step width is a good compromise as the common value for new tpc algorithms.
>>
>> If you use 0.5db units for that struct, then it will support anything with that granularity or higher.
>> But, fine with me if you want to just have it be 1db units.
>>
> using 0.5db is more appropriate for the already existing chips that
> support this granularity, and is more future-proof.
> 1db units may be easier to handle for the API and/or TPC algorithms
> but again limits existing hardware capabilities.
>
>>> The ath9k chips I have used so far support a minimum tx-power of -5dBm (=0,32mW), Mediatek has a min of 0dBm (=1mW)… so I would argue to use 0dBm (=1mW) as common minimum tx-power value, as the any possible spatial reuse gain happens from 0dBm up to max tx-power.
>>
>> If a chip supports setting to txpower to -5, then why not let the API support that? Have The value -128
>> be 'do not set', and anything else will mean 'try to set the chip to this power or the nearest thing to it
>> that the chip supports'.
>
> I agree with that, having -128 as value for 'not set' or 'invalid'
> would leave the negative dBm for chips that support this.
> Whether the TPC then actually makes use of this should not be the
> reason to use 0 as default.
>
> To your previous question:
> retry_count = 1 is intended to be a single tx, so naming the struct
> member 'try_count' would be more appropriate?
Yes, I think so.
In my own hackings, I have also used a try_count of '0' to mean try once
but request NOACK on the frame. I am not sure if that even applies in
your case though...
Thanks,
Ben
>
> Besides this, I will add proper documentation for this in the
> following patch version to clarify the units and meanings.
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
next prev parent reply other threads:[~2022-03-10 17:33 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-09 19:57 [PATCH v2 0/2] mac80211: extend current rate control tx status API Jonas Jelonek
2022-03-09 19:57 ` [PATCH v2 1/2] " Jonas Jelonek
2022-03-09 20:38 ` Ben Greear
2022-03-10 16:07 ` Thomas Hühn
2022-03-10 16:43 ` Ben Greear
2022-03-10 17:27 ` Jonas Jelonek
2022-03-10 17:33 ` Ben Greear [this message]
2022-03-09 19:57 ` [PATCH v2 2/2] mac80211: minstrel_ht: support ieee80211_rate_status Jonas Jelonek
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=0a447b8e-647f-2f0e-4444-35792974e1e6@candelatech.com \
--to=greearb@candelatech.com \
--cc=jelonek.jonas@gmail.com \
--cc=johannes@sipsolutions.net \
--cc=kvalo@kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=nbd@nbd.name \
--cc=thomas@inet.tu-berlin.de \
/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