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
