Re: [RFC][v1][Design] AP Architecture for Roaming with Wi-Fi 8 Seamless Mobility Domain (SMD)

Hi Benjamin,

On 10/30/2025 01:47, Benjamin Berg wrote:
> 
> Do we have a clear picture of what the performance issues might be?
> 
> To me, it seems a bit that talking about threading might be a red
> heering. It could be that the primary issue is the prioritization of
> events when there is a burst of activity.
> 
> We should not need threading as long as each individual event can be
> processed quickly and hostapd is able to keep up overall. In that case,
> we have an event ordering issue which can likely be solved by using
> multiple nl80211 sockets and giving them different priorities in the
> mainloop. By doing that, you can effectively pull all time-critical
> events to the front of the queue and ensure they are processed with
> only a short delay.
> 
> Now, that doesn't invalidate your point at all. If we do have tasks
> that take a long time (crypto?, external requests?), then it can make
> sense to push just the slow part into a separate thread and pick up
> processing in the main thread once it has finished.
To preface our concerns: the longer the context transfer takes, the
less time the serving AP has available to drain its remaining packets
before hitting the SN limit. This can result in a larger gap in
client-perceived latency during roaming depending on when the target
AP is ready to start DL transmission. Efficient handling of the
context transfer (during the ST Execution phase) is therefore key to
minimize client-perceived latency.

You've accurately captured the core performance concerns we intended
to highlight:
1. _Prioritization of Management Frames:_
   Certain management frames - such as SMD - should be able to "skip
   the line" since a roam request typically will indicate degraded
   client link quality and prioritizing immediate transition over
   processing existing management traffic is likely in the client's
   best interest - especially after preparation has already completed.
2. _Additional Threads for Long-Polled Operations:_
   Without multi-threading, long-polled netlink messages or system
   calls can block even the prioritized kernel events. As you noted,
   offloading slow operations that are busy waiting to worker threads
   can allow the main thread to handle time-critical events.

That said, even with multi-threading in hostapd, we still face
overhead from RTNL locks and netlink socket overhead — not only from
hostapd of the serving MLD but also from other hostapd processes tied
to other MLDs on the AP. This is why we initially proposed moving the
ST Execution sequence to mac80211. Doing so could reduce round-trip
latency from ST Execution Request to Response, especially under high
system load and concurrent work across multiple hostapd interfaces.

> 
> Benjamin
>


Regards,
Aditya