It would also require some other new attributes, like when you add an MLD station you'd of course have to give the link addresses for each of the links, but all of those things are required anyway. The alternative - having the different wdevs/netdevs as we have seen in the RFC patches and discussed before seems to have a lot of issues. We basically discussed a few approaches so far: 1) My original favourite of adding NL80211_IFTYPE_MLD, which would then have a netdev and get a bunch of non-netdev NL80211_IFTYPE_(STATION|AP) linked to it, and know what it is based on that. Problem: you'd have to change the interface type (and destroy the links, but that's less interesting, though it might actually take quite some time with synchronize_rcu and all in there) when roaming from an MLO AP to a non-MLO AP. 2) A variant of this, which was discussed even earlier, where the APs also have netdevs, so that you can separate the traffic from non-MLD clients. Problem: Now you have to deal with multicast in very fancy ways, especially since you don't immediately know if all the netdevs are bridged together, or only some, etc. This gets hugely complex, you even need to still assign sequence numbers for multicast on the separate non- MLD netdevs from the MLD ... I cannot see this working well. 3) Doing it the other way around - having NL80211_IFTYPE_(STATION|AP) be the MLD (with netdev) and adding an NL80211_IFTYPE_MLD_LINK (no netdev) that gets linked to it, and knows what kind it is because it's linked. This solves the roaming. Problem: As you have to set the GTK on the _MLD_LINK wdev, it gets extremely messy to support AP_VLAN here, you'd likely have to have AP_VLAN under the AP as MLD, so you can add MLD stations to it, but then you need _MLD_LINKs for each link for the AP_VLAN as well? I cannot see how that would really work well... This latter issue actually came up only because I said to Jouni that the issue of separating non-MLD clients out addressed by (2) above could instead be solved by putting them into different AP_VLAN, which then got me thinking about AP_VLAN in the context of MLD :) [1] Which then leads me to think that maybe the approach with some form of separate netdev/wdev, that I at least seemed to think was better (in part because it'd require fewer API changes), isn't so great after all? And then I'm back at adding a LINK_ID and splitting the wdev/sdata/vif state in a similar way to the station splitting in this patch. Thoughts? Oh also I've been thinking about doing a (video) meeting say next week or so, in order to hash out this stuff, but I guess timezone wise that might be very difficult with the different locations people are in? johannes [1] I'll note that if we solve the non-MLD client separation issue with AP_VLAN, we might want to optimize multicast a bit to restrict to a subset of the links that are actually used by the clients that the multicast is intended for, but that's probably something we want to do anyway, since you might at any given time have only legacy clients connected to only a single band or a subset of bands, or have an MLD client that has many inactive links (depending on how the spec ends up evolving in this area).
