Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <6ee9c93cfa5a8f6dbb6e07dc2c72e26bb0e57121.camel@sipsolutions.net>
Subject: Re: [PATCH 10/19] wifi: iwlwifi: limit EHT capabilities based on
 PCIe link speed
From:   Johannes Berg <johannes@sipsolutions.net>
To:     Ben Greear <greearb@candelatech.com>, gregory.greenman@intel.com
Cc:     linux-wireless@vger.kernel.org
Date:   Wed, 21 Jun 2023 16:51:11 +0200
In-Reply-To: <9f4c589a-2160-cedb-d79a-1f57ea5244da@candelatech.com>
References: <20230620100405.45117-1-gregory.greenman@intel.com>
         <20230620125813.b77a1574a0a7.Id4120c161fb7df6dedc70d5f3e3829e9117b8cb1@changeid>
         <d220c5b6-7c8f-19cd-12d0-ceb484e29e48@candelatech.com>
         <53612acba151d031f636626db20c1c60db09fdd0.camel@sipsolutions.net>
         <9f4c589a-2160-cedb-d79a-1f57ea5244da@candelatech.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.48.3 (3.48.3-1.fc38) 
MIME-Version: 1.0
Precedence: bulk

On Wed, 2023-06-21 at 07:48 -0700, Ben Greear wrote:
> On 6/21/23 4:57 AM, Johannes Berg wrote:
> > On Tue, 2023-06-20 at 06:19 -0700, Ben Greear wrote:
> > > On 6/20/23 3:03 AM, gregory.greenman@intel.com wrote:
> > > > From: Johannes Berg <johannes.berg@intel.com>
> > > >=20
> > > > If a discrete NIC is connected to a PCIe link hat isn't at least
> > > > Gen3 (8.0 GT/s), then we cannot sustain 320 MHz traffic, so remove
> > > > that from EHT capabilities in that case.
> > > >=20
> > > > While at it, also move setting 320 MHz beamformee to the right
> > > > place in the code so it's not set while not supporting 320 MHz.
> > >=20
> > > Is there not an advantage to allowing 320Mhz for longer distance conn=
ections
> > > where signal is relatively weak, so over-all tput would easily fit in=
 lesser
> > > pcie bus?  Especially on 6E band where the US regdom allows more over=
-all power
> > > when using wider bandwidths?
> > >=20
> >=20
> > I actually don't know. This surely isn't ideal, but it's the only way t=
o
> > really force the AP to not send too much than the NIC can pass out, and
> > it gets unhappy if it can't.
>=20
> So this is to work around hardware/firmware bug in NIC?  If so, that shou=
ld
> be mentioned.

I'm not sure that's really even a _bug_, it just doesn't have a lot of
buffer space inside of it; as far as I know, given how the HW
architecture works, the FW doesn't have a lot of options.

> I have heard in the past that higher bandwidth works better than higher N=
SS
> in a lot of cases, so if HW/FW can be made to deal with floods in unlikel=
y
> case that the RF is perfect enough to saturate the PCI bus, then I think =
you
> should allow 320Mhz even on slower PCI bus configurations.

Right. I don't think it's likely that the firmware will do, but hey, I
can let them know :)

johannes