Received-SPF: pass (google.com: domain of linux-wireless+bounces-3535-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Message-ID: <3c550ae335a9762a9cbd0c8109b6dd99faeb8f6f.camel@sipsolutions.net>
Subject: Re: [PATCH v8 4/5] wifi: mac80211: start and finalize channel
 switch on link basis
From: Johannes Berg <johannes@sipsolutions.net>
To: Aditya Kumar Singh <quic_adisi@quicinc.com>
Cc: linux-wireless@vger.kernel.org, Jeff Johnson
 <quic_jjohnson@quicinc.com>,  Ilan Peer <ilan.peer@intel.com>, Jouni
 Malinen <j@w1.fi>, Ping-Ke Shih <pkshih@realtek.com>, Ryder Lee
 <ryder.lee@mediatek.com>
Date: Tue, 13 Feb 2024 13:49:09 +0100
In-Reply-To: <18c0d4de-392a-420c-8a05-466a83cd2eb8@quicinc.com>
References: <20240130140918.1172387-1-quic_adisi@quicinc.com>
	 <20240130140918.1172387-5-quic_adisi@quicinc.com>
	 <b73dd1f9c23c164179c38e2109aa1550d87e87ed.camel@sipsolutions.net>
	 <646d1e3e404a437f4c99c80996eb4f194ac242b8.camel@sipsolutions.net>
	 <26df9aa6-e497-4040-ad5c-c647454acca6@quicinc.com>
	 <b2cf5c1d-7842-4e59-b25a-904a6879fa9c@quicinc.com>
	 <f7174207668cac149246cafa0e4b4749ee3289f0.camel@sipsolutions.net>
	 <ac5825e8-0cb1-476e-be5c-ad0170122f77@quicinc.com>
	 <fe2100dcfe9ae9b4517f239faf25374c27f473a5.camel@sipsolutions.net>
	 <5c0fd2eb-eb19-4b69-a325-ad9eef633336@quicinc.com>
	 <bc81466177afd0014ccdd9030c5807339bb288db.camel@sipsolutions.net>
	 <18c0d4de-392a-420c-8a05-466a83cd2eb8@quicinc.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.50.3 (3.50.3-1.fc39) 
Precedence: bulk
MIME-Version: 1.0

On Tue, 2024-02-13 at 18:11 +0530, Aditya Kumar Singh wrote:
> > > Correct. Both has got its own advantages and disadvantages. Need to
> > > agree on any one so that all can be benefited. Let's hear from other =
folks.
> >=20
> > Do you _have_ firmware for this already, perhaps?
> >=20
>=20
> Yes, private firmware is there. Not yet upstreamed since the=20
> infrastructure in mac80211 and driver is not there. AFAIK it is in=20
> pipeline. Internal testing have so far been good and did not see any=20
> issues. So at least from Qualcomm perspective, we are fine with=20
> offloading (the above we discussed) to firmware.

Ah, OK.

Note that if we have all the offsets I guess you could still do all the
parsing? Though adding the per-STA profile in cross-link scenarios would
be a difference if hostapd has to do it in the template vs. firmware
copying the elements ...

For the record, I really don't like copying the elements and not sure
I'd want to implement that in mac80211/hwsim...

> > I mean, I'm happy to be designing this "greenfield", but ... it seems
> > unlikely at this point?
> >=20
> > Also what about ath12k with the multi-device changes, would the driver
> > have to handle it? Or I guess you have to sync the TSF somehow anyway,
> > so you could handle it based on TSF/TBTT?
> >=20
>=20
> Ath12k firmware also supports beacon offload and hence firmware is=20
> taking care to add the respective IEs in per-STA profile of the=20
> reporting links while host just sends the template for the affected link=
=20
> via beacon template update and indicating that critical update has happen=
ed.

OK. So I guess we have to support that? Or are there any chances we
could agree on something here overall and then the firmware can be
changed to support another mode?

> > That seems messy for all the reasons I mentioned, since it involves
> > parsing/defragmenting/merging/fragmenting per-STA profiles etc.
> >=20
> > Do you really want to go there?
> >=20
>=20
> I understand things looks to be messy. But at least internally we have=
=20
> done in that way and things look simpler (on kernel level). Not sure=20
> whether all firmwares would agree to that.

And hwsim, but yeah :)

> > Not sure what you mean here - we can still offload beaconing with a
> > template, just have to fill in the template a bit more (with partner
> > link CSA counters rather than just own CSA counters)?
> > > I'm basically thinking this:
> >=20
> > 1. Firmware is aware of partner link CSA counters/TSF offset/TBTT
> >=20
> > 2. Host driver (hostapd) sets beacon template of affected link to
> > include CSA elements, and already today we include in the setting the
> > offset to the countdown fields, so it doesn't matter where those are.
> >=20
> > 3. Host driver (hostapd) *also* updates beacon templates of partner
> > links, but instead of saying "here's the CSA counter to update" it says
> > "here's the CSA counter for your partner link M to set" (OK, so there
> > potentially are multiple of those, but that's OK)
> >=20
> > 4. Firmware doesn't need to parse anything, it just needs to go through
> > the beacon when transmitting it (for any link) and set the CSA counter
> > fields for the link itself and/or for the partner links according to
> > what the correct counter is per TBTT rules, TSF offset, beacon interval
> > etc.
> >=20
>=20
> Hmm.. I see your point. So basically there is tradeoff - complexity of=
=20
> handling the parsing and all in firmware or complexity of handling those=
=20
> many offsets in kernel. I believe when hostapd updates the templates for=
=20
> the partner links, it would have to send offsets so we may need to=20
> extend our NL infrastructure for MLO in order to accommodate all those=
=20
> list of offsets during beacon template update.

Yes, of course. But that doesn't seem _too_ complicated? Even supporting
max # of links (14) and ~3 counters each isn't a huge list... netlink
doesn't care, and drivers have lower link limits anyway.

Maybe I'll do a prototype later? But for now

 a) I need to test the client-side code I'm writing in some other way
    (element injection or something)

 b) let's wait for Realtek to comment also after the Lunar New Year :)

Thanks!

johannes