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;
Subject: Re: [PATCH 10/19] wifi: iwlwifi: limit EHT capabilities based on PCIe
 link speed
To:     Johannes Berg <johannes@sipsolutions.net>,
        gregory.greenman@intel.com
Cc:     linux-wireless@vger.kernel.org
References: <20230620100405.45117-1-gregory.greenman@intel.com>
 <20230620125813.b77a1574a0a7.Id4120c161fb7df6dedc70d5f3e3829e9117b8cb1@changeid>
 <d220c5b6-7c8f-19cd-12d0-ceb484e29e48@candelatech.com>
 <53612acba151d031f636626db20c1c60db09fdd0.camel@sipsolutions.net>
From:   Ben Greear <greearb@candelatech.com>
Organization: Candela Technologies
Message-ID: <9f4c589a-2160-cedb-d79a-1f57ea5244da@candelatech.com>
Date:   Wed, 21 Jun 2023 07:48:38 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.10.1
MIME-Version: 1.0
In-Reply-To: <53612acba151d031f636626db20c1c60db09fdd0.camel@sipsolutions.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-MW
Content-Transfer-Encoding: 7bit
Precedence: bulk

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