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;
Sender: msinada=codeaurora.org@mg.codeaurora.org
DMARC-Filter: OpenDMARC Filter v1.4.1 smtp.codeaurora.org A7BC1C43460
From:   "Muna Sinada" <msinada@codeaurora.org>
To:     "'Johannes Berg'" <johannes@sipsolutions.net>
Cc:     <linux-wireless@vger.kernel.org>
References: <1627587701-13134-1-git-send-email-msinada@codeaurora.org> <6d85542f47955cdac0137c72b0de04e5c0fe0799.camel@sipsolutions.net>
In-Reply-To: <6d85542f47955cdac0137c72b0de04e5c0fe0799.camel@sipsolutions.net>
Subject: RE: [PATCH v2] nl80211: Add HE UL MU fixed rate setting
Date:   Thu, 26 Aug 2021 16:08:34 -0700
Message-ID: <001601d79acf$4bb85b80$e3291280$@codeaurora.org>
MIME-Version: 1.0
Content-Type: text/plain;
        charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Language: en-us
Thread-Index: AQIuihlKfyOVzPIK6v2sETi2yH8wDgHs4TVrqskX2AA=
Precedence: bulk

Hello Johannes,

I agree that it is odd to combine this new attribute with the existing =
parameters. I will be removing "he_ul_mcs" out of cfg80211_bitrate_mask =
and passing it as a separate attribute in next version.

Thank you,
Muna=20

-----Original Message-----
From: Johannes Berg <johannes@sipsolutions.net>=20
Sent: Tuesday, August 17, 2021 6:49 AM
To: Muna Sinada <msinada@codeaurora.org>
Cc: linux-wireless@vger.kernel.org
Subject: Re: [PATCH v2] nl80211: Add HE UL MU fixed rate setting

Hi,

On Thu, 2021-07-29 at 12:41 -0700, Muna Sinada wrote:
> This patch adds nl80211 definitions, policies and parsing code=20
> required to pass HE UL MU fixed rate settings.
>=20

I don't understand how this is sufficient?

>  		enum nl80211_txrate_gi gi;
>  		enum nl80211_he_gi he_gi;
>  		enum nl80211_he_ltf he_ltf;

Previously, for HE rates, we had configurations for:
 * HE MCS
 * HE guard interval
 * HE LTF

I guess I can sort of follow that uplink traffic is a bit different and =
not already configured by the setting for rate control we have today, =
but why does it not need all these parameters?

Also, why is this not a per-station parameter? OK, maybe we don't really =
want it to be a per-station parameter, or maybe the firmware/algorithm =
that's selecting things there can't deal with that, but it feels odd to =
combine it with the "rate control fixed rate" parameters you have here, =
and do that without even any explanation of how this is supposed to =
work.

This is going to need some work.

johannes