Re: [PATCH 10/19] wifi: iwlwifi: limit EHT capabilities based on PCIe link speed

[Ben Greear <greearb@candelatech.com>]

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>
>>>
>>> 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.
>>>
>>> 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.
>>
>> Is there not an advantage to allowing 320Mhz for longer distance connections
>> 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?
>>
> 
> I actually don't know. This surely isn't ideal, but it's the only way to
> really force the AP to not send too much than the NIC can pass out, and
> it gets unhappy if it can't.

So this is to work around hardware/firmware bug in NIC?  If so, that should
be mentioned.

I have heard in the past that higher bandwidth works better than higher NSS
in a lot of cases, so if HW/FW can be made to deal with floods in unlikely
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.

Thanks,
Ben

> 
> johannes
> 


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