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.
> >
> > Do you _have_ firmware for this already, perhaps?
> >
>
> Yes, private firmware is there. Not yet upstreamed since the
> infrastructure in mac80211 and driver is not there. AFAIK it is in
> pipeline. Internal testing have so far been good and did not see any
> issues. So at least from Qualcomm perspective, we are fine with
> 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?
> >
> > 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?
> >
>
> Ath12k firmware also supports beacon offload and hence firmware is
> taking care to add the respective IEs in per-STA profile of the
> reporting links while host just sends the template for the affected link
> via beacon template update and indicating that critical update has happened.
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.
> >
> > Do you really want to go there?
> >
>
> I understand things looks to be messy. But at least internally we have
> done in that way and things look simpler (on kernel level). Not sure
> 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:
> >
> > 1. Firmware is aware of partner link CSA counters/TSF offset/TBTT
> >
> > 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.
> >
> > 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)
> >
> > 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.
> >
>
> Hmm.. I see your point. So basically there is tradeoff - complexity of
> handling the parsing and all in firmware or complexity of handling those
> many offsets in kernel. I believe when hostapd updates the templates for
> the partner links, it would have to send offsets so we may need to
> extend our NL infrastructure for MLO in order to accommodate all those
> 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
