public inbox for linux-wireless@vger.kernel.org
 help / color / mirror / Atom feed
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


  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