On Fri, 2025-06-27 at 07:21 -0700, Jeff Johnson wrote: > On 6/27/2025 12:39 AM, Johannes Berg wrote: > > Hi, > > > > So I held off for a while since I didn't want anyone to think I have it > > covered ;-) > > > > > Specific areas of interest at this time include: > > > Robust AV Streaming (IEEE Std 802.11-2020 section 11.25) > > > Seamless Roaming (IEEE P802.11bn/D0.2, March 2025 section 37.9) > > > > But of course generally with my maintainer hat on I'm interested, and to > > some extend perhaps the seamless roaming overlaps a bit with client? > > > > Now that I learned more about it though, it seems the seamless roaming > > isn't even all _that_ seamless, and doesn't require major surgery? > > I think you have a typo: s/doesn't/does/ :) (I didn't) > Seamless roaming is meant to be seamless to the end user but definitely not > seamless to the underlying client or the AP code. And although the scope isn't > as bad as MLO (we hope), it is still a complex handshake, and there are some > things that will be in our proposal will definitely need discussion. OK, I look forward to seeing that then, maybe I'm just completely wrong. Especially the AP part seemed fairly simple from the kernel space POV to me since it just has to keep the STA alive for long enough to drain out all the pending frames, while already having redirected the L2 to the new AP. The APs will maintain two STAs but that's split over two APs too, so shouldn't be that bad? Although I suppose if you get someone trying to do seamless roaming from one link of an AP MLD to another link of an AP MLD ... but I don't think it works that way? It also has to copy state like the PN/SN etc. but that's also not architecturally challenging, I'd think? The client part also didn't seem nearly as bad as I had anticipated; yes, we have to swap from the old to the new AP more seamlessly, but we don't have to support two AP STAs at the same time, just drain traffic while queuing new TX traffic and then swap over quickly without dropping the STA. Perhaps at a mac80211 level we still create a new STA but then have an atomic 'swap()' callback to the driver? Haven't thought about it too hard yet. > The reason my team is focused on the AP part is that, as reported earlier, for > Wi-Fi 8 we want to transition to upstream for all of our AP products. Our > primary Wi-Fi 8 client will continue to use the downstream qcacld driver, so > client design is currently a lower priority for my team. Perhaps Intel can > drive that :) We definitely will be working on the client side. johannes
