On Mon, Jul 14, 2025 at 4:59 PM nithp@xxxxxxxxxxxxxxxx
<nithp@xxxxxxxxxxxxxxxx> wrote:
>
>
>
> -----Original Message-----
> From: Johannes Berg <johannes@xxxxxxxxxxxxxxxx>
> Sent: Tuesday, July 8, 2025 5:46 PM
> To: jeff.johnson@xxxxxxxxxxxxxxxx; Nithyanantham Paramasivam (QUIC) <quic_nithp@xxxxxxxxxxx>
> Cc: linux-wireless@xxxxxxxxxxxxxxx; nbd@xxxxxxxx
> Subject: Re: [PATCH wireless-next v2 0/2] wifi: cfg80211/mac80211/ath12k: Enable monitor creation in NO_VIRTUAL_MONITOR mode when AP is active
>
> WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.
>
> Hi,
>
> Sorry, I keep starting to look at this, and then confuse myself, and couldn't seem to offer coherent thoughts so far. I'm still not sure I can, so I'll just offer possibly incoherent ones instead now ;-)
>
> > > Please share your thoughts on the following query
> > >
> > > In the virtual monitor mode design, only a single monitor interface
> > > per radio was supported and subsquent monitor creation shares the
> > > same vif. However, in NO_VIRTUAL_MONITOR mode(multi-wiphy scenario),
> > > there is no limitation on the number of interfaces that can be
> > > created (due to separate SDATA for each interface) and notified to the driver.
> > > For example, the ath driver can handle up to 16 interfaces per radio.
> > > Should we impose any limitations in cfg80211/mac80211 ?
>
> I think that question really should be if you _want_ to? I already feld that the NO_VIRTUAL_MONITOR is a hack that goes away from what this had originally intended (which was allowing the creation of arbitrary monitor interfaces that may or may not be related to the operation of the HW), but I think we just didn't find a good way to handle it otherwise in multi-radio scenarios.
>
> With the benefit of hindsight, I'd say that to best match the original behaviour,
> * we wouldn't have NO_VIRTUAL_MONITOR,
> * so you could create as many monitor interfaces as you'd like;
> * each one would report frames (perhaps according to the radio mask
> (3607798ad9bd ("wifi: cfg80211: add option for vif allowed radios")))
> rather than filtering by the _channel_ set on it;
> * you'd be able to set the channel on a monitor only within its radio
> mask and if the radio needed for the channel was actually free.
>
> This would require tracking things more in mac80211, possibly creating a virtual monitor interface per radio. I don't remember if I thought it too complex, or Felix did? I briefly tried reading through the old RFC and PATCH postings but not much answer there.
>
> Do we want that? It seems no. All the "coordinate multiple monitor interfaces in the kernel" seems to be a fringe use case nobody with a voice really cared about, or they're not using the latest versions yet.
> I still think it's somehow technically nicer since you don't have to sync things in userspace, but if nobody cares why have it...
>
>
> However, in some way this would seem to move us further away from such an ideal state, so it seems almost like we should then cover monitor interfaces by the (per-radio) interface combinations instead of continuing to pretend they're virtual constructs? Even with the NO_VIRTUAL_MONITOR we were already at a point where
>
> /* mac80211 always supports monitor */
> hw->wiphy->interface_modes |= BIT(NL80211_IFTYPE_MONITOR);
> hw->wiphy->software_iftypes |= BIT(NL80211_IFTYPE_MONITOR);
>
> didn't _actually_ make sense.
>
> So I think it's probably time to remove that if NO_VIRTUAL_MONITOR is set, and then cover it by the interface combinations. That way, maybe instead of adding WIPHY_FLAG_SUPPORTS_CONCUR_MONITOR_N_OTHER_VIF (and that name ... super long) we can check in cfg80211 if monitor is a software iftype, and if _not_ then just let it go through since we assume that the lower layer will check the interface combinations?
>
> Or actually improve mac80211 to the point where we can do what I outlined above?
>
> As it stands, this seems a bit half-cooked?
>
> johannes
Thanks, Johannes, for the detailed explanation. Since adopting virtual
monitor mode would require substantial changes in mac80211, we'll
proceed with the NO_MONITOR_MODE approach and aim to address the gaps
by considering all relevant scenarios. Sure, I'll treat the monitor
interface as a non-software interface type and rely on the interface
combination checks for validation.
