From: Johannes Berg <johannes@sipsolutions.net>
To: Felix Fietkau <nbd@nbd.name>
Cc: linux-wireless@vger.kernel.org
Subject: Re: [RFC 3/6] wifi: mac80211: notify driver about per-radio monitor enabled state
Date: Tue, 17 Sep 2024 10:13:14 +0200 [thread overview]
Message-ID: <8a0cb794de71bab324bdc1bb68ba58488ab925b3.camel@sipsolutions.net> (raw)
In-Reply-To: <47BF11DD-ECD1-4314-AD1B-B58A99724DFB@nbd.name>
On Fri, 2024-08-23 at 13:26 +0200, Felix Fietkau wrote:
>
> > On 23. Aug 2024, at 12:16, Johannes Berg <johannes@sipsolutions.net> wrote:
> >
> > On Mon, 2024-08-05 at 21:23 +0200, Felix Fietkau wrote:
> > > This allows monitoring on one or more radios while minimizing performance
> > > impact on the others.
> >
> > But why are you doing it this way? You could already solve this entirely
> > with the driver by setting WANT_MONITOR_VIF and dealing with that, I'd
> > think? At least after this series.
> >
> > I generally don't like hw->conf, it just hasn't really matched reality
> > for years with all kinds of new concurrency capabilities. At the very
> > least you'd have to write more text here to convince me that we want to
> > add something to it ... :)
>
> I really don’t see how WANT_MONITOR_VIF helps. It seems completely unrelated to me, since it only creates a single driver visible vif, if there are no non-monitor vifs on the phy.
Well, it's true that it only creates one towards the driver, but that
one vif can also only be bound to a single channel context, and
therefore a single radio.
If we actually want(ed) to support monitoring on different radios
simultaneously we'd have to change mac80211 quite a bit, and probably
introduce multiple virtual monitor interfaces. Internally, we _always_
have it now, to be able to bind a channel context, so we'd actually need
multiple - one for each possible parallel channel.
So that's why I think having WANT_MONITOR_VIF helps - you can assume
today that only one chanctx can be used for monitoring, and once you
have the monitor vif in hand, you know which one it is. Therefore you
know which radio it is, and can adjust your offloads/etc. accordingly.
> I want to be able to control, which radios I want to capture on, regardless of which vifs are already active on the same phy.
Sure.
> A global monitor enable/disable status means that I can’t prevent monitor-incompatible offloads from being disabled on radios that I’m not monitoring on.
>
Yeah I'd just say don't use that state, but the presence of the monitor
vif, and you can figure out which radio it's present on.
johannes
next prev parent reply other threads:[~2024-09-17 8:13 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-05 19:23 [RFC 0/6] wifi: cfg80211/mac80211: improve support for multiple radios Felix Fietkau
2024-08-05 19:23 ` [RFC 1/6] wifi: cfg80211/mac80211: add option for vif allowed radios Felix Fietkau
2024-08-05 19:23 ` [RFC 2/6] wifi: mac80211: remove status->ampdu_delimiter_crc Felix Fietkau
2024-08-05 19:23 ` [RFC 3/6] wifi: mac80211: notify driver about per-radio monitor enabled state Felix Fietkau
2024-08-23 10:16 ` Johannes Berg
2024-08-23 11:26 ` Felix Fietkau
2024-09-17 8:13 ` Johannes Berg [this message]
2024-09-17 15:26 ` Ben Greear
2024-08-05 19:23 ` [RFC 4/6] wifi: mac80211: support per-radio driver start/stop calls Felix Fietkau
2024-08-23 10:17 ` Johannes Berg
2024-08-23 11:31 ` Felix Fietkau
2024-09-17 8:59 ` Johannes Berg
2024-08-05 19:23 ` [RFC 5/6] wifi: mac80211: support per-radio filter flags Felix Fietkau
2024-08-23 10:20 ` Johannes Berg
2024-08-23 16:26 ` Felix Fietkau
2024-09-17 9:01 ` Johannes Berg
2024-08-05 19:23 ` [RFC 6/6] wifi: mac80211: check vif radio_mask for monitor mode rx Felix Fietkau
2024-08-23 10:23 ` Johannes Berg
2024-08-23 17:33 ` Felix Fietkau
2024-09-17 9:03 ` Johannes Berg
2024-08-23 10:14 ` [RFC 0/6] wifi: cfg80211/mac80211: improve support for multiple radios Johannes Berg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8a0cb794de71bab324bdc1bb68ba58488ab925b3.camel@sipsolutions.net \
--to=johannes@sipsolutions.net \
--cc=linux-wireless@vger.kernel.org \
--cc=nbd@nbd.name \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox