Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: [PATCH v5 07/11] mt76: mt7915: add support for tx-overrides
To:     Kalle Valo <kvalo@codeaurora.org>
Cc:     linux-wireless@vger.kernel.org
References: <20210804134505.3208-1-greearb@candelatech.com>
 <20210804134505.3208-7-greearb@candelatech.com>
 <875yw1bhgu.fsf@tynnyri.adurom.net>
From:   Ben Greear <greearb@candelatech.com>
Organization: Candela Technologies
Message-ID: <52135b51-1a5f-1ff9-5c81-cd970cb4b311@candelatech.com>
Date:   Thu, 19 Aug 2021 09:16:46 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.2.2
MIME-Version: 1.0
In-Reply-To: <875yw1bhgu.fsf@tynnyri.adurom.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 8/19/21 8:08 AM, Kalle Valo wrote:
> greearb@candelatech.com writes:
> 
>> From: Ben Greear <greearb@candelatech.com>
>>
>> Allow setting fix rate on transmit without using full testmode
>> logic.
> 
> Why?

I use it for testing purposes, so I can send specific frame encodings
to see if peer can receive it or not (receiver sensitivity testing).

Others may be interested in similar API to test that their system transmits
specific MCS frames at proper txpower or other regulatory-related stuff.

And to some degree, the underlying logic gives clever people a way to do driver-defined
per-skb rate-control instead of depending on the firmware.  I hacked similar thing
into my ath10k and at least one person attempted that as I recall.

> 
>> txpower, dynbw, retry count is not currently supported.
>> And, probably later need additional logic to not apply this
>> txo to non-data frames and to smaller frames, to allow
>> ARP and such to go through while also forcing test data frames
>> to arbitrary tx-rates (rates which very well may not be
>> received by peer.)
> 
> Please include an example how to use the debugfs file.

It is in the patch:

+	const char buf[] =
+		"This allows specify specif tx rate parameters for all DATA"
+		" frames on a vdev\n"
+		"To set a value, you specify the dev-name and key-value pairs:\n"
+		"tpc=10 sgi=1 mcs=x nss=x pream=x retries=x dynbw=0|1 bw=x enable=0|1\n"
+		"pream: 0=cck, 1=ofdm, 2=HT, 3=VHT, 4=HE_SU\n"
+		"cck-mcs: 0=1Mbps, 1=2Mbps, 3=5.5Mbps, 3=11Mbps\n"
+		"ofdm-mcs: 0=6Mbps, 1=9Mbps, 2=12Mbps, 3=18Mbps, 4=24Mbps, 5=36Mbps,"
+		" 6=48Mbps, 7=54Mbps\n"
+		"tpc is not implemented currently, bw is 0-3 for 20-160\n"
+		" For example, wlan0:\n"
+		"echo \"wlan0 tpc=255 sgi=1 mcs=0 nss=1 pream=3 retries=1 dynbw=0 bw=0"
+		" active=1\" > ...mt76/set_rate_override\n";

> 
> IIRC there was a similar rtw88 patch adding a debugfs to force setting
> the tx rate. So what's the consensus, are we going to allow each driver
> have their own custom interfaces setting tx rates? In my opinion this
> should go via a generic nl80211 command, but if people think having
> custom tx rate interfaces is ok I guess I need to reconsider.
> 
> As this patch needs more discussion, please separate it from rest of the
> series so that it can be applied separately.

Ok, will do.

Thanks,
Ben


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com