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

[Johannes Berg]

On Wed, 2025-11-05 at 13:26 -0800, Aditya Sathish wrote:
> Continuing on a message excerpt I missed from Johannes' earlier response,
> since it is in a similar vein to Benjamin's response:
> 
> On 10/12/2025 06:51, Johannes Berg wrote:
> > That's not _really_ a good argument though - mac80211 will likely have
> > to process this in process context, likely acquire wiphy mutex, etc.
> The ST Execution sequence — which includes receiving the ST Execution
> Request, sending context, receiving a status code from the target AP MLD,
> and ultimately sending the ST Execution Response — is largely client-
> driven. It primarily involves parsing management frame content and
> handling context data embedded in the skb as extensions by the vendor
> driver.
> 
> From the target AP MLD side, we do need to access the generated group keys
> to include in the ST Execution Response to the client. However, beyond that,
> interaction with core wiphy data structures is minimal.

Fair.

> While it's likely that mac80211 will operate in process context, if our goal
> is to minimize latency as much as possible, we believe it should be feasible
> to implement the ST Execution logic without acquiring the wiphy mutex. This
> could be achieved by isolating the ST Execution path and leveraging a
> high-priority workqueue, thereby avoiding unnecessary contention and
> improving latency. However, this is, admittedly, dependent on the tolerance
> for complexity in the mac80211 versus the demonstrated benefit - which is
> something we are gathering experimental data for.

There _is_ a possibility also that nl80211 operations do not need to
take the wiphy mutex, though of course that might be more complex.
Probably less complex than pushing everything into the kernel though :)

But yeah, I think data on it would be the best way to settle it.

johannes