On Fri, 12 Apr 2024 at 09:02, Vasanthakumar Thiagarajan <quic_vthiagar@xxxxxxxxxxx> wrote: > On 4/12/2024 1:08 PM, Nicolas Escande wrote: > > On Fri Apr 12, 2024 at 5:50 AM CEST, Vasanthakumar Thiagarajan wrote: > >> On 4/11/2024 10:09 PM, Maxime Bizon wrote: > >>> > >>> On Thu, 2024-04-11 at 21:56 +0530, Vasanthakumar Thiagarajan wrote: > >>> > >>> Hello, > >>> > >>> Thanks for making it clear, > >>> > >>> > >>>>> For example, starting a 5Ghz AP in ax-only mode, and at the same > >>>>> time > >>>>> creating a STA interface on 2.4GHz ? > >>> > >>>> Yes, such use cases continue to be supported in single wiphy mode. > >>> > >>> Understood, but I see some corner cases. > >>> > >>> > >>> For example, assume two bands AP hardware, 2.4GHz and 5GHz. > >>> > >>> Previously: > >>> - phy0 is 2.4Ghz > >>> - phy1 is 5Ghz > >>> - iw phy phy0 interface create wlan0 type managed > >>> - iw dev wlan0 scan > >>> > >>> => will only scan 2.4Ghz > >>> > >>> > >>> With single phy approach: > >>> - phy0 is 2.4Ghz + 5Ghz concurrent > >>> - # iw phy phy0 interface create wlan0 type managed > >>> - # iw dev wlan0 scan > >>> .> >>> => will scan both bands ? > >>> > >> > >> Yes, both the bands will be scanned if freq list is not given > >> > >>> - <starting from previous state> > >>> - # iw phy phy0 interface create wlan1 type __ap > >>> - # hostapd -i wlan1 <config> > >>> - # iw dev wlan0 scan > >>> > >>> => what will happen then ? > >>> > >> > >> Scan will be carried out on all the radios including the one on which AP interface is > >> running. Scan with freq list can be used not to disturb the radio of AP interface. > >> > >>>> Same goes for hostapd ACS, I assume specifying freqlist becomes > >>> mandatory or we can't predict which band the AP will be on ? > >>> > >> > >> If no freq list is given, ACS will run through all the bands and select a channel from any > >> of the bands. But this can be optimized to do ACS and channels selection on a particular > >> band using channellist/freqlist hostapd configurations. > > Hello, > > > > And in a (very unlikely) case that there are two underlying radios that can > > operate on the same frequencies, how would freqlist enable us to really select > > the underlying radio ? > > > > This can not be supported in this approach. As only the radios participating in MLO are > supposed to be combined under one wiphy, not sure if we have real use case to combine > radios of same frequencies. > > Vasanth > Looking at this discussion, I think it would really be helped with some architectural diagrams describing the various combinations of components in an RF chain. Let us take a single example. We have antennas, analogue front end, and ADCs (Analogue to digital converters) The features of those two are: 1) Antennas can be optimised for particular frequencies. 2) The analogue front end has many different parameters, but for this discussion, the important one is: a) frequencies it can tune to. b) instantaneous bandwidth. I.e. When tuned to a particular frequency, what is the bandwidth around that frequency that one can receive. 3) ADC a) The Sample rate Once the RF sample are in the digital domain one has the ADC -> DIgital Processing -> Output data If we assume that the ADC is set to receive the full instantaneous bandwidth, the digital processing can do a number of things. 1) process the full instantaneous bandwidth into a single channel of data. 2) process the instantaneous bandwidth into multiple sub bands, or multiple channels of data. There is also the control endpoint that controls all these components. There can be multiple front ends for each ADC. multiple ADCs per Digital Processing. A higher level process (maybe hostapd) can then speak to multiple Digital Processing and ADC, RF Front end components and then somehow has to manage and coordinate them all. All these capabilities and varying arrangement of the various components need to be reported up to a higher level, in a common way, that can handle all possible arrangements. Once the higher level process has all this information, it can then manage to do everything necessary for Multi-Link operation (MLO). So, to answer some of the questions in this thread. Scanning: The high level process should know what capabilities are available and what can be done in parallel or not. So it should be able to convert a request from a user, into a more detailed request down towards the hardware. I.e. User asks for scan. High level process tells which bits of the hardware should do the scanning and across which frequencies. While it might sound complicated, when implemented correctly, it is just a matter of iterating over a tree with a search match criteria. My expertise is in managing far more complex RF hardware and not Wifi specifically, but the concepts for managing the hardware across all the available frequencies is the same. I am just offering a perspective of where the problems discussed here have already been solved in another domain.