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

[Aditya Sathish]

Hi Johannes,

Thank you for your response!

On 10/12/2025 06:51, Johannes Berg wrote:
> Would be nice btw to get feedback on the NPCA stuff I posted, now that
> you can apparently talk about UHR 😉
You should be hearing from the NPCA team soon regarding this topic.

> I _really_ think you should _not_ design it that way right now. To the
> point where I think I'm going to just reject adding that to mac80211 at
> this stage, unless a real need can be demonstrated.
>
We understand your concerns on offloading ST Execution and inter-AP
communication to mac80211 in the first draft. We are in the process of
curating more concrete experimental data that can highlight the real
benefits (and possible shortcomings) of operating ST Execution and the
latency-critical inter-AP communication within the kernel space.

Until then, we intend to continue with hostapd-managed _non-offload_ ST
Preparation, ST Execution and the inter-AP communication framework -
handling inter-AP messaging from hostapd directly through socket-based
communication and processing the SMD management frames within the current
architecture of hostapd (extending on the FT infrastructure for inter-AP).

> A good part of this argument - "pending management frames" - really goes
> back to hostapd's architecture and single-threadedness, but really I
> don't think "hostapd's current architecture implies more latency"
> implies "we must put this into the kernel."
>
> Continuing that thought: I think that hostapd's architecture currently
> leaves a lot to be desired, in particular around how MLD works, and
> obviously, at least to some extent, being single-threaded is an
> architectural advantage in hostapd.
>
> However, user space also affords far more flexibility than kernel space,
> for example some things could be written in rust (with its "fearless
> concurrency", which I can attest to), split out to a separate thread or
> process, etc.
>
> Anyway ... I guess in a way I'm using the opportunity here to lament the
> lack of architectural work in hostapd which isn't necessarily related to
> this, but I suspect that had hostapd historically had more architectural
> flexibility we might not even be having this discussion?
On hostapd architecture: we have had internal discussions with Jouni and
recognize the limitations of its single-threaded model at least in context
of SMD roaming. We are yet to identify any features outside of SMD which
holds a critical latency requirement. As such, we see _full_ multi-threading
as a significant undertaking without any users of this benefit outside of
SMD (at least at this time).

Given this, we are exploring an alternative approach — introducing worker
threads for low-priority kernel events while enabling prioritized handling
for sequences like ST Execution and the inter-AP messaging in the main
thread. This could offer a tractable path to bring multi-threading without
having to do a deep-dive study on the impact of parallelism on existing
features.

To summarize,
(1) We will defer offloading the ST Execution and inter-AP communication
    to mac80211 until we are ready to demonstrate the need. Until then,
    we will proceed with hostapd-based ST Preparation, ST Execution and
    inter-AP communication.
(2) We are planning to explore the introduction of worker threads for low-
    priority kernel events while enabling prioritized handling for
    sequences like ST Execution in the main thread.

Regards,
Aditya

Regards,
Aditya