Received: by 2002:a25:e7d8:0:0:0:0:0 with SMTP id e207csp3621018ybh; Tue, 17 Mar 2020 03:35:18 -0700 (PDT) X-Google-Smtp-Source: ADFU+vsGUKUNV0VOUJHTci4LUPJqiByd+JdK+0fUIjBEJ2otQ1JlwlKu2uZaDDx114o8WuNt0OsQ X-Received: by 2002:aca:bad7:: with SMTP id k206mr2809136oif.78.1584441318405; Tue, 17 Mar 2020 03:35:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1584441318; cv=none; d=google.com; s=arc-20160816; b=U2Fh/Ac7xELLxSJ3p2UH2J6XegvhCiU2g1idFN8kzFWSULyHRhLriG5FDhtV4EEwe3 CX084qL1OafsqIJBfxhqU1Lw1aj8Xrze/4AVWjT+svToyaoWdWwTSnSvr7Qq1qPmRCjv No9DrS+1j3u+J6+LK0zsZbgQjKaQfvtPD4qFM/K3Q1JYCS0iTuj+fPgeND9kwzD5FnvX XMo4FSMEvoD6UA0uc5hG27gFsvzPbGOqRds6o2DbaLA6EN4o6lbVa7F4n6DW6sKzmzHu uGOjgHWnGF/v0Gt+XDRIdPWGUZCuY3jOp9ejDqObEWWjAxLpMMfqOhqWx3iZQKjiIuT8 DKDQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:content-transfer-encoding :content-language:accept-language:in-reply-to:references:message-id :date:thread-index:thread-topic:subject:cc:to:from:authenticated-by; bh=ggHEQAMdGPAtbiwjUZZYYH2bZYm1foo33TbcMcp8K+w=; b=O3hl26vQqnlS9JTL3O/k5aqb3S7HdkncLuns6lXIi10aFJblpR4Odq1i2Z7iJ/7EfR ckMBUFFeYOd9ANq7aTbir265o91QxVor3wQVvbnkk8BNks8mMNu1q1jy/i1RxQiilpfc XSjhduJVoOU4ZFv+OoB7/vZ4C5oks1w+mjR9hSV6jkG8CQBoLKVIOh3vh4HkiiaeI6Li mogNCMrZ7jbNRz66hP+Mad7HujDzWCQ9LF39Jw5H7NW6MqEpKPC/6+Ox0GMnBBAov3Bw kDJokPAlQhcITWTs0YtdLvc+APRqt11WVHBLiDYzRKsTr3lORysIe5NX1umTIoWBji0l 7N8g== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-wireless-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-wireless-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id c14si1566849otm.146.2020.03.17.03.35.06; Tue, 17 Mar 2020 03:35:18 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-wireless-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-wireless-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-wireless-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726066AbgCQKdQ convert rfc822-to-8bit (ORCPT + 99 others); Tue, 17 Mar 2020 06:33:16 -0400 Received: from rtits2.realtek.com ([211.75.126.72]:57739 "EHLO rtits2.realtek.com.tw" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725868AbgCQKdQ (ORCPT ); Tue, 17 Mar 2020 06:33:16 -0400 Authenticated-By: X-SpamFilter-By: BOX Solutions SpamTrap 5.62 with qID 02HAWwVp025210, This message is accepted by code: ctloc85258 Received: from mail.realtek.com (RTEXMB06.realtek.com.tw[172.21.6.99]) by rtits2.realtek.com.tw (8.15.2/2.57/5.78) with ESMTPS id 02HAWwVp025210 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 17 Mar 2020 18:32:58 +0800 Received: from RTEXMB01.realtek.com.tw (172.21.6.94) by RTEXMB06.realtek.com.tw (172.21.6.99) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1779.2; Tue, 17 Mar 2020 18:32:58 +0800 Received: from RTEXMB04.realtek.com.tw (172.21.6.97) by RTEXMB01.realtek.com.tw (172.21.6.94) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1779.2; Tue, 17 Mar 2020 18:32:58 +0800 Received: from RTEXMB04.realtek.com.tw ([fe80::d9c5:a079:495e:b999]) by RTEXMB04.realtek.com.tw ([fe80::d9c5:a079:495e:b999%6]) with mapi id 15.01.1779.005; Tue, 17 Mar 2020 18:32:58 +0800 From: Tony Chuang To: Kalle Valo , Johannes Berg CC: "linux-wireless@vger.kernel.org" , "briannorris@chromium.org" Subject: RE: [PATCH] rtw88: add debugfs to fix tx rate Thread-Topic: [PATCH] rtw88: add debugfs to fix tx rate Thread-Index: AQHV+QPS9h9ZLy9E5U2M/GVMmM07xahGU7JUgAQrRBCAAeVFp4AANj0w Date: Tue, 17 Mar 2020 10:32:58 +0000 Message-ID: References: <20200313065114.23433-1-yhchuang@realtek.com> <87eetwo87q.fsf@kamboji.qca.qualcomm.com> <2e492e530d744713871f885e324106ef@realtek.com> <87eetrlanb.fsf@kamboji.qca.qualcomm.com> In-Reply-To: <87eetrlanb.fsf@kamboji.qca.qualcomm.com> Accept-Language: zh-TW, en-US Content-Language: zh-TW X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.21.68.175] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 Sender: linux-wireless-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org // Add Johannes for commenting on adding another nl80211 commands Kalle Valo writes:> > Tony Chuang writes: > > > Kalle Valo writes: > > > >> writes: > >> > >> > From: Yan-Hsuan Chuang > >> > > >> > 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 > >> > >> 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. 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). 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. > > > I am sorry I need to add another debugfs for it, but to actually fix the TX > > bitrate, we really need another debugfs or module parameter. Because > > according to the design of the device there is not a good enough general > > command I can use to fix the TX rate. If there is a command that can fix > > the TX bitrate for me, please let me know, I can switch to it. > > Sorry, but I'm not yet convinced that a debugfs file is justified. > Fixing a transmit bitrate sounds like a very generic command, not > something which should be in debugfs. > Thanks. Yen-Hsuan