Re: [PATCH wireless-next v8 2/3] wifi: cfg80211: add initial UHR support

[Manish Dharanenthiran <manish.dharanenthiran@oss.qualcomm.com>]

On 3/13/2026 1:02 AM, Johannes Berg wrote:
> 
>>> Because of this, an event-driven approach was considered.
> 
> So - starting this again from scratch. Benjamin and I spent some time
> discussing this today too, and hashed out a (mostly?) workable solution
> that should address most of the issues. I'll try to summarise that
> below.
> 
Thanks for the detailed summary.

> As will become obvious - and that's why I quoted only the line _you_
> wrote before - this means we (including myself :)) need to stop being
> afraid of hostapd doing (soft?) real-time [1] tasks...
> 
> [1] I'm using that word in the (formal) sense of having a deadline, not
> of having to be particularly fast.
> 
> 
> Let's assume the following constraints:
> 
> - preparing a beacon template as a real-time task can be done by
> hostapd, given enough heads-up time
> - no periodic events in a steady state when the AP is operating
> normally
> - TSF drift between links is correctly handled (maintaining <=30us
> offset at any time)
> 

Handling beacon template within TBTT interval between links is possible 
in a model implementation but in real-time low-cost platforms where the 
AP is handling max clients (256) with multiple vdevs enabled might be a 
overhead for user-space to process.

> We evidently already make these assumptions:
> 
> - if beacon intervals are not the same, the TBTT offset in RNR is
> filled in by firmware (I see no way around this)
> - either firmware fills in TSF offset, or it's just zero, and not
> really accounting for slight drifts (but that's probably OK since it
> never adds up given the <=30us requirement)
> 
> And also let's introduce some new operations to driver/firmware:
> 
> - the firmware can drop a frame that it's not able to transmit before
> a given (as frame metadata) TSF value on the link, and indicate to
> the driver that this is the reason the frame was dropped
> - the firmware can create events at/after beacon TBTT (or beacon
> transmission), this can be controlled by the driver; these events
> contain the next TBTT's timestamp value
> - the TSF offsets between links can be known to the driver, if they can
> change (I suspect CSA could do that?) this can somehow be noticed by
> or given to the driver
> 
> With that, it seems we can redesign this whole thing to be event-driven
> and (mostly?) race-free.
> 
> In steady state, basically nothing would change from what hostapd is
> doing today. It simply configures beacon templates, occasionally updates
> them if elements need to change, and sends probe responses,
> (re)association responses etc. as usual.
> 
> During any sort of update (CSA, color change, EHT updates, UHR updates)
> things operate a bit differently:
> 
> 1) hostapd enables TBTT / beacon transmit events, these events would be
> generated by firmware and passed up, for each link, containing also the
> TBTT timestamp of the _next_ beacon to be transmitted
> 
> 2) hostapd waits for the TBTT event for the link that it wants to do the
> update on, ignoring events for other links
> 
> 3) starting from that TBTT event, on each TBTT event hostapd generates a
> new beacon template for the link the event was for, and configures it to
> the driver/firmware. Since that's a future beacon, it has to predict the
> content of that beacon using
> - the TBTT of the first beacon carrying the update announcement
> - the TSF offsets between the links
> - the beacon intervals of all the links
> (a bit more on this later)
> 
> 4) After applying the updates (a bit more on this later) and noticing
> that the announcements are finished, hostapd waits for one more TBTT
> event for each link and configures the beacons back to steady state,
> after which it turns off the events.
> 
> If, at any time during this, hostapd needs to send a probe response,
> (re)association response, EPP Capa/Operation response (or others?) which
> holds information about the updates with the current counter values,
> hostapd will create the frame per the current counters that it
> maintains, and will transmit this frame with a TSF cut-off value
> indicating that it must be transmitted before the next TBTT (over all
> links), or dropped.
> If this frame ends up being dropped by firmware because it didn't get
> out before the indicated TSF, hostapd gets a specific notification for
> this and then simply re-generates it and sends it again. This could
> possibly repeat if TBTTs are close together on multiple links, but I
> think it's not worth optimising for this case, though it could be done
> by deferring the response slightly based on timers, or at the expense of
> a more complex API ("defer until X and don't send after Y" vs. "don't
> send after Y"), neither seems really worthwhile.
> 

For dense client situations where we have the AP in a stadium or in any 
crowded place, the clients are moving between APs, we see that there 
will be more traffic drops for client connected as it gets dropped due 
to above condition. (Also, there is a chance the station might add the 
AP to the blacklist if there are more rejection while associating)

> 
> I said I'd give more information for (3) and (4) above, so:
> 
> For (3), also consider that it already has to effectively be able to do
> this for the templates thing we discussed, it has to predict what each
> link is going to look like in the future. I think this isn't too much of
> an issue, but care must be taken especially if beacon intervals differ.
> 
> For (4), I think the way how the updates are done may depend on what the
> update is. If, for example, it's DBE increasing the bandwidth, then
> could just do the update _before_ the 0 beacon is transmitted, and if
> it's decreasing bandwidth could do it _after_ the 0 beacon is
> transmitted. Some of these may potentially require management by the
> kernel or even driver/firmware (how do you switch NPCA parameters at the
> exact right point if not in FW?), and perhaps (especially for CSA?)

In offloaded case, firmware takes care of removing the newly added 
element(s) once the beacon with count 1 is sent. For CSA and ML 
reconfig, fimrware will send a completion event from which kernel/driver 
data will be updated.

> there will be some considerations regarding multiple interfaces.
> I mostly think this question is orthogonal, since armed with a TBTT
> hostapd could also request that this update be done at a given TBTT.
> 
> 
As mentioned above, this gets tricky in the cases which involves a low 
cost platforms in a dense client scenario. Users might not like having a 
glitch in their traffic (especially during live streaming) :)

> We haven't really been able to poke significant holes into this, but
> maybe that doesn't mean much. Couple of thoughts on that:
> 
>   * For each link, hostapd has roughly the whole beacon interval to build
>     the next beacon's template, which seems reasonable.
>   * There's a really weird corner case where an assoc response is
>     attempted to transmit just before a beacon, doesn't get an ACK, but a
>     retransmission isn't possible until after the beacon and it's dropped
>     due to the TSF cut-off. Doesn't seem worth worrying about.
>   * If the TBTTs for two links are at the same time, and the events to
>     userspace for them are not coming "updated link first", then the
>     beacon transmitted at the same time on the unchanged link may not yet
>     be announcing the update, depending on the event order, given that
>     hostapd waited for the affected link's first TBTT event. This doesn't
>     really seem like a problem, but I think could be addressed by
>     updating all the links on the first event immediately or so, or
>     (Benjamin prefers this I think) adding the first beacon's TBTT to the
>     response to the event enable command, I just worry that would cause
>     other races that would need to be addressed.
> 
> That's it for now :) Let me know what you think.
> 
> johannes

Thanks for the detailed answer with clear explanation. Yes, this is not 
much racy as we saw in the previous designs and addressed most of them.
We do think that this is suitable for the cases where the CPU load is 
very much low, also the time sensitiveness with respect to client 
handling is not a problem.

But, in real time use cases where the AP is getting deployed in crowded 
places, the CPU load spikes which might cause more traffic drops or 
connectivity issues. Also, if the AP is enabled with cloud analyzer 
which collects periodic stats, load will be high, thus chances for the 
user-space application to get the CPU cycle is highly subjective. That's 
why we preferred a offload solution where most of the time sensitive 
operation are within the firmware.

We will come up with a offloaded design that would be scalable for the 
upstream driver(s), also address the hwsim cases where we would want a 
minimal test cases for handling CU to facilitate upstream STA 
implementations.

Regards
Manish Dharanenthiran