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@xxxxxxxxx wrote:
From: Johannes Berg <johannes.berg@xxxxxxxxx>
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@xxxxxxxxxxxxxxx>
Candela Technologies Inc http://www.candelatech.com
