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

Hi,

On Wed, 2025-10-29 at 16:17 -0700, Aditya Sathish wrote:
> [SNIP]
>=20
> > A good part of this argument - "pending management frames" - really goe=
s
> > 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."
> >=20
> > 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.
> >=20
> > 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.
> >=20
> > Anyway ... I guess in a way I'm using the opportunity here to lament th=
e
> > lack of architectural work in hostapd which isn't necessarily related t=
o
> > this, but I suspect that had hostapd historically had more architectura=
l
> > 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 contex=
t
> 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-thread=
ing
> as a significant undertaking without any users of this benefit outside of
> SMD (at least at this time).
>=20
> Given this, we are exploring an alternative approach =E2=80=94 introducin=
g worker
> threads for low-priority kernel events while enabling prioritized handlin=
g
> for sequences like ST Execution and the inter-AP messaging in the main
> thread. This could offer a tractable path to bring multi-threading withou=
t
> having to do a deep-dive study on the impact of parallelism on existing
> features.

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.

Benjamin

> To summarize,
> (1) We will defer offloading the ST Execution and inter-AP communication
> =C2=A0=C2=A0=C2=A0 to mac80211 until we are ready to demonstrate the need=
. Until then,
> =C2=A0=C2=A0=C2=A0 we will proceed with hostapd-based ST Preparation, ST =
Execution and
> =C2=A0=C2=A0=C2=A0 inter-AP communication.
> (2) We are planning to explore the introduction of worker threads for low=