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@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'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 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. Right. I don't think it's likely that the firmware will do, but hey, I can let them know :) johannes
