| Message ID | 1607526302-8063-1-git-send-email-usdutt@codeaurora.org |
|---|---|
| State | New |
| Headers | show |
| Series | [RFC] Introduce NL80211_IFTYPE_MLO_LINK_DEVICE for MLO link (IEEE 802.11be) | expand |
Hi, > Multi-link support is introduced in 802.11be specification. [...] I'll definitely have to take a closer look at this and the spec and think about it - but a couple of quick comments below. > @@ -3131,6 +3139,7 @@ enum nl80211_iftype { > NL80211_IFTYPE_P2P_DEVICE, > NL80211_IFTYPE_OCB, > NL80211_IFTYPE_NAN, > + NL80211_IFTYPE_MLO_LINK_DEVICE, You'll probably have to update some mac80211 code in this patch to avoid compiler warnings. > +void cfg80211_stop_mlo_link_device(struct cfg80211_registered_device *rdev, > + struct wireless_dev *wdev) > +{ > + ASSERT_RTNL(); > + > + if (WARN_ON(wdev->iftype != NL80211_IFTYPE_MLO_LINK_DEVICE)) > + return; > + > + if (!wdev_running(wdev)) > + return; > + > + rdev_stop_mlo_link_device(rdev, wdev); > + wdev->is_running = false; > + > + rdev->opencount--; > + > + if (rdev->scan_req && rdev->scan_req->wdev == wdev) { > + if (WARN_ON(!rdev->scan_req->notified && > + (!rdev->int_scan_req || > + !rdev->int_scan_req->notified))) > + rdev->scan_req->info.aborted = true; > + ___cfg80211_scan_done(rdev, false); > + } Does it even make sense to allow scanning on this wdev, rather than on the normal client interfaces? Perhaps should just not be able to get there? > @@ -718,6 +718,7 @@ static const struct nla_policy nl80211_policy[NUM_NL80211_ATTR] = { > [NL80211_ATTR_SAE_PWE] = > NLA_POLICY_RANGE(NLA_U8, NL80211_SAE_PWE_HUNT_AND_PECK, > NL80211_SAE_PWE_BOTH), > + [NL80211_ATTR_MLO_LINK_INFO] = { .type = NLA_NESTED }, That should specify what/how it's nested, using NLA_POLICY_NESTED_ARRAY() (I think, in this case) > struct sk_buff *msg; > void *hdr; > + struct nlattr *nested, *nested_mlo_links; > + struct cfg80211_mlo_link_device_params *mlo_link; > + int i = 0; > > msg = nlmsg_new(100 + cr->req_ie_len + cr->resp_ie_len + > cr->fils.kek_len + cr->fils.pmk_len + > - (cr->fils.pmkid ? WLAN_PMKID_LEN : 0), gfp); > + (cr->fils.pmkid ? WLAN_PMKID_LEN : 0) + > + (cr->n_mlo_links ? cr->n_mlo_links * 32 : 0), gfp); 32 probably should be some NLA_SIZE or something constant? There's also no point in the ternary operator since 0 * 32 is 0 :) > /* Consumes bss object one way or another */ > @@ -833,7 +849,9 @@ void cfg80211_connect_done(struct net_device *dev, > ev = kzalloc(sizeof(*ev) + (params->bssid ? ETH_ALEN : 0) + > params->req_ie_len + params->resp_ie_len + > params->fils.kek_len + params->fils.pmk_len + > - (params->fils.pmkid ? WLAN_PMKID_LEN : 0), gfp); > + (params->fils.pmkid ? WLAN_PMKID_LEN : 0) + > + (params->n_mlo_links ? params->n_mlo_links * > + sizeof(struct cfg80211_mlo_link_device_params) : 0), gfp); same here, no need for the ternary It feels strangely asymmetric to have stop and no start ... but I guess that's the part where I need to think about it and look a bit at how it all works :) johannes
On 09-12-2020 16:36, Johannes Berg wrote: > Hi, > >> Multi-link support is introduced in 802.11be specification. > [...] > > I'll definitely have to take a closer look at this and the spec and > think about it - but a couple of quick comments below. Did not get my hands on the spec yet, but just firing random thoughts. This multi-link support sounds a bit like bonding. Could that be leveraged for wireless? I wonder why there is a need for a non-netdev interface. Does networking layer need to be aware of the multi-link for scheduling traffic to it? Is there one driver per multi-link or per radio? [...] >> struct sk_buff *msg; >> void *hdr; >> + struct nlattr *nested, *nested_mlo_links; >> + struct cfg80211_mlo_link_device_params *mlo_link; >> + int i = 0; >> >> msg = nlmsg_new(100 + cr->req_ie_len + cr->resp_ie_len + >> cr->fils.kek_len + cr->fils.pmk_len + >> - (cr->fils.pmkid ? WLAN_PMKID_LEN : 0), gfp); >> + (cr->fils.pmkid ? WLAN_PMKID_LEN : 0) + >> + (cr->n_mlo_links ? cr->n_mlo_links * 32 : 0), gfp); > > 32 probably should be some NLA_SIZE or something constant? Probably sizeof(*mlo_link) ? > There's also no point in the ternary operator since 0 * 32 is 0 :) > >> /* Consumes bss object one way or another */ >> @@ -833,7 +849,9 @@ void cfg80211_connect_done(struct net_device *dev, >> ev = kzalloc(sizeof(*ev) + (params->bssid ? ETH_ALEN : 0) + >> params->req_ie_len + params->resp_ie_len + >> params->fils.kek_len + params->fils.pmk_len + >> - (params->fils.pmkid ? WLAN_PMKID_LEN : 0), gfp); >> + (params->fils.pmkid ? WLAN_PMKID_LEN : 0) + >> + (params->n_mlo_links ? params->n_mlo_links * >> + sizeof(struct cfg80211_mlo_link_device_params) : 0), gfp); > > same here, no need for the ternary > > > It feels strangely asymmetric to have stop and no start ... but I guess > that's the part where I need to think about it and look a bit at how it > all works :) Had the same feeling in my gutt (wherever that is ;-) Regards, Arend -- This electronic communication and the information and any files transmitted with it, or attached to it, are confidential and are intended solely for the use of the individual or entity to whom it is addressed and may contain information that is confidential, legally privileged, protected by privacy laws, or otherwise restricted from disclosure to anyone else. If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient, you are hereby notified that any use, copying, distributing, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you received this e-mail in error, please return the e-mail to the sender, delete it from your computer, and destroy any printed copy of it.
On 2020-12-14 14:55, Arend van Spriel wrote: > On 09-12-2020 16:36, Johannes Berg wrote: >> Hi, >> >>> Multi-link support is introduced in 802.11be specification. >> [...] >> >> I'll definitely have to take a closer look at this and the spec and >> think about it - but a couple of quick comments below. Thanks for your comments. Please allow me to address your comments in the subsequent patches. Our main intention through this RFC is to get the view on the proposal to introduce a new NL80211_IFTYPE for an MLO Link. Please suggest on this. > Did not get my hands on the spec yet, but just firing random thoughts. > This multi-link support sounds a bit like bonding. Could that be > leveraged for wireless? I wonder why there is a need for a non-netdev > interface. Does networking layer need to be aware of the multi-link > for scheduling traffic to it? Is there one driver per multi-link or > per radio? The following is what the Bonding driver / interface does for the multiple network interfaces. 1. Bonding driver aggregates multiple network interfaces into a single logical bonded interface. 2. Each network interface is called as a slave in the bonding driver. 3. It’s the Bonding driver that schedules the traffic across these slaves. 4. Bonding interface operates on one of the following modes ( mentioning for a quick reference ). balance-rr : Round-robin policy: Transmit packets in sequential order from the first available slave through the last. active-backup : Only one slave in the bond is active. A different slave becomes active if, and only if, the active slave fails. balance-xor : Transmit based on the selected transmit hash policy. balance-tlb : channel bonding that does not require any special switch support. The outgoing traffic is distributed according to the current load balance-alb : includes balance-tlb plus receive load balancing. 5. With the above modes, the scheduling of the traffic is determined with in the kernel / bonding driver and have the host driver / firmware follow it. The following are the factors for not considering the MLO Link as a bonding interface and further to propose this RFC (new NL80211_IF_TYPE -> NL80211_IFTYPE_MLO_LINK_DEVICE). 1. For MLO, our intention is to allow the traffic scheduling (among the MLO links) to be closer to the lower layers in the driver/firmware, etc, unlike the bonding driver where kernel schedules the traffic. 2. If MLO Link has to use a bonding interface, each MLO link has to be associated with a network interface and thus each of the MLO link has to be of NL80211_IF_TYPE -> NL80211_IFTYPE_STATION. 3. This further means that NL80211_CONNECT / NL80211_ASSOCIATE needs to get triggered on each of this MLO Link of the MLO connection. 4. Our intention is to consider the MLO station as a single network interface . More specifically, have a single NL80211_CONNECT / NL80211_CMD_ASSOCIATE triggered for each MLO connection ( MLD + MLO Links). 5. The reason we had to introduce a new NL80211_IF_TYPE -> NL80211_IFTYPE_MLO_LINK_DEVICE is to have the corresponding link connection specific information ( e.g., Connection State, Connected BSS Info, Connection Frequency/properties, etc), for each wdev / MLO Link and at the same time have a single connect / association request to the driver / AP. 6. Further, these NL80211_IFTYPE_MLO_LINK_DEVICE link devices shall represent an MLO Link and attribute to a network interface ( MLD ) of an MLO connection. 7. The current proposal to introduce a new NL80211_IF_TYPE should support the architectures of MLO links across the multiple wiphy interfaces or on the same wiphy interface. These wiphy interfaces can be from different drivers too. Please review the above. > > [...] > >>> struct sk_buff *msg; >>> void *hdr; >>> + struct nlattr *nested, *nested_mlo_links; >>> + struct cfg80211_mlo_link_device_params *mlo_link; >>> + int i = 0; >>> msg = nlmsg_new(100 + cr->req_ie_len + cr->resp_ie_len + >>> cr->fils.kek_len + cr->fils.pmk_len + >>> - (cr->fils.pmkid ? WLAN_PMKID_LEN : 0), gfp); >>> + (cr->fils.pmkid ? WLAN_PMKID_LEN : 0) + >>> + (cr->n_mlo_links ? cr->n_mlo_links * 32 : 0), gfp); >> >> 32 probably should be some NLA_SIZE or something constant? > > Probably sizeof(*mlo_link) ? > >> There's also no point in the ternary operator since 0 * 32 is 0 :) >> >>> /* Consumes bss object one way or another */ >>> @@ -833,7 +849,9 @@ void cfg80211_connect_done(struct net_device >>> *dev, >>> ev = kzalloc(sizeof(*ev) + (params->bssid ? ETH_ALEN : 0) + >>> params->req_ie_len + params->resp_ie_len + >>> params->fils.kek_len + params->fils.pmk_len + >>> - (params->fils.pmkid ? WLAN_PMKID_LEN : 0), gfp); >>> + (params->fils.pmkid ? WLAN_PMKID_LEN : 0) + >>> + (params->n_mlo_links ? params->n_mlo_links * >>> + sizeof(struct cfg80211_mlo_link_device_params) : 0), gfp); >> >> same here, no need for the ternary >> >> >> It feels strangely asymmetric to have stop and no start ... but I >> guess >> that's the part where I need to think about it and look a bit at how >> it >> all works :) > > Had the same feeling in my gutt (wherever that is ;-) Sure. Will take this point. In fact, this was documented in the commit message to consider the start (say start_mlo_link), but do not want the drivers to depend on this trigger for starting the MLO link. For example, the host drivers with SME can as well start the MLO Link after getting the Assoc response for MLO links from the AP. > > Regards, > Arend
On 2020-12-23 21:59, usdutt@codeaurora.org wrote: > On 2020-12-14 14:55, Arend van Spriel wrote: >> On 09-12-2020 16:36, Johannes Berg wrote: >>> Hi, >>> >>>> Multi-link support is introduced in 802.11be specification. >>> [...] >>> >>> I'll definitely have to take a closer look at this and the spec and >>> think about it - but a couple of quick comments below. > > Thanks for your comments. Please allow me to address your comments in > the subsequent patches. > Our main intention through this RFC is to get the view on the proposal > to introduce a new NL80211_IFTYPE for an MLO Link. > Please suggest on this. > > >> Did not get my hands on the spec yet, but just firing random thoughts. >> This multi-link support sounds a bit like bonding. Could that be >> leveraged for wireless? I wonder why there is a need for a non-netdev >> interface. Does networking layer need to be aware of the multi-link >> for scheduling traffic to it? Is there one driver per multi-link or >> per radio? > > The following is what the Bonding driver / interface does for the > multiple network interfaces. > 1. Bonding driver aggregates multiple network interfaces into a single > logical bonded interface. > 2. Each network interface is called as a slave in the bonding driver. > 3. It’s the Bonding driver that schedules the traffic across these > slaves. > 4. Bonding interface operates on one of the following modes ( > mentioning for a quick reference ). > balance-rr : Round-robin policy: Transmit packets in sequential > order from the first available slave through the last. > active-backup : Only one slave in the bond is active. A > different slave becomes active if, and only if, the active slave > fails. > balance-xor : Transmit based on the selected transmit hash > policy. > balance-tlb : channel bonding that does not require any special > switch support. The outgoing traffic is distributed according to the > current load > balance-alb : includes balance-tlb plus receive load balancing. > 5. With the above modes, the scheduling of the traffic is determined > with in the kernel / bonding driver and have the host driver / > firmware follow it. > > The following are the factors for not considering the MLO Link as a > bonding interface and further to propose this RFC > (new NL80211_IF_TYPE -> NL80211_IFTYPE_MLO_LINK_DEVICE). > > 1. For MLO, our intention is to allow the traffic scheduling (among > the MLO links) to be closer to the lower layers in > the driver/firmware, etc, unlike the bonding driver where > kernel schedules the traffic. > 2. If MLO Link has to use a bonding interface, each MLO link has to be > associated with a network interface and thus each > of the MLO link has to be of NL80211_IF_TYPE -> > NL80211_IFTYPE_STATION. > 3. This further means that NL80211_CONNECT / NL80211_ASSOCIATE needs > to get triggered on each of this MLO Link of the > MLO connection. > 4. Our intention is to consider the MLO station as a single network > interface . More specifically, have a single > NL80211_CONNECT / NL80211_CMD_ASSOCIATE triggered for each MLO > connection ( MLD + MLO Links). > 5. The reason we had to introduce a new NL80211_IF_TYPE -> > NL80211_IFTYPE_MLO_LINK_DEVICE is to have the corresponding > link connection specific information ( e.g., Connection State, > Connected BSS Info, Connection Frequency/properties, etc), > for each wdev / MLO Link and at the same time have a single > connect / association request to the driver / AP. > 6. Further, these NL80211_IFTYPE_MLO_LINK_DEVICE link devices shall > represent an MLO Link and attribute to a network interface ( MLD ) of > an > MLO connection. > 7. The current proposal to introduce a new NL80211_IF_TYPE should > support the architectures of MLO links across the multiple wiphy > interfaces or on the same wiphy interface. These wiphy > interfaces can be from different drivers too. > > Please review the above. > >> >> [...] >> >>>> struct sk_buff *msg; >>>> void *hdr; >>>> + struct nlattr *nested, *nested_mlo_links; >>>> + struct cfg80211_mlo_link_device_params *mlo_link; >>>> + int i = 0; >>>> msg = nlmsg_new(100 + cr->req_ie_len + cr->resp_ie_len + >>>> cr->fils.kek_len + cr->fils.pmk_len + >>>> - (cr->fils.pmkid ? WLAN_PMKID_LEN : 0), gfp); >>>> + (cr->fils.pmkid ? WLAN_PMKID_LEN : 0) + >>>> + (cr->n_mlo_links ? cr->n_mlo_links * 32 : 0), gfp); >>> >>> 32 probably should be some NLA_SIZE or something constant? >> >> Probably sizeof(*mlo_link) ? >> >>> There's also no point in the ternary operator since 0 * 32 is 0 :) >>> >>>> /* Consumes bss object one way or another */ >>>> @@ -833,7 +849,9 @@ void cfg80211_connect_done(struct net_device >>>> *dev, >>>> ev = kzalloc(sizeof(*ev) + (params->bssid ? ETH_ALEN : 0) + >>>> params->req_ie_len + params->resp_ie_len + >>>> params->fils.kek_len + params->fils.pmk_len + >>>> - (params->fils.pmkid ? WLAN_PMKID_LEN : 0), gfp); >>>> + (params->fils.pmkid ? WLAN_PMKID_LEN : 0) + >>>> + (params->n_mlo_links ? params->n_mlo_links * >>>> + sizeof(struct cfg80211_mlo_link_device_params) : 0), gfp); >>> >>> same here, no need for the ternary >>> >>> >>> It feels strangely asymmetric to have stop and no start ... but I >>> guess >>> that's the part where I need to think about it and look a bit at how >>> it >>> all works :) >> >> Had the same feeling in my gutt (wherever that is ;-) > > Sure. Will take this point. In fact, this was documented in the commit > message to consider the start (say start_mlo_link), but do not want > the drivers to depend on this trigger for starting the MLO link. > For example, the host drivers with SME can as well start the MLO Link > after getting the Assoc response for MLO links from the AP. > > >> >> Regards, >> Arend Hi, Can you please provide your comments on the proposal. We wanted to hear your feedback on the following points. Represent MLO link of an MLO connection by a wdev of type NL80211_IFTYPE_MLO_LINK_DEVICE. MLO link wdev does not have an active netdev associated to it but will be similar to that of NL80211_IFTYPE_STATION, w.r.t maintaining link’s connection information ( connected channel , BSSID, etc). MLD interface of an MLO connection will be a station interface (NL80211_IFTYPE_STATION wdev) This station interface shall link the wdev’s of all the MLO link wdev’s part of the MLO connection. Cfg80211 layer shall link all such wdev’s. Such MLO Link wdev’s shall be part of the same wiphy or different wiphy (if host driver's register a single wiphy for each supported band/MAC/PHY). MLO link wdev (NL80211_IFTYPE_MLO_LINK_DEVICE) is created by the user space prior the MLO connection. User space can as well change the interface type among NL80211_IFTYPE_STATION wdev To NL80211_IFTYPE_MLO_LINK_DEVICE wdev. To support the use case where an existing STA wdev can change to a MLO wdev and vice versa. Regards, Sunil
On 2/9/2021 3:48 PM, usdutt@codeaurora.org wrote: > On 2020-12-23 21:59, usdutt@codeaurora.org wrote: >> On 2020-12-14 14:55, Arend van Spriel wrote: >>> On 09-12-2020 16:36, Johannes Berg wrote: >>>> Hi, >>>> >>>>> Multi-link support is introduced in 802.11be specification. >>>> [...] >>>> >>>> I'll definitely have to take a closer look at this and the spec and >>>> think about it - but a couple of quick comments below. >> >> Thanks for your comments. Please allow me to address your comments in >> the subsequent patches. >> Our main intention through this RFC is to get the view on the proposal >> to introduce a new NL80211_IFTYPE for an MLO Link. >> Please suggest on this. >> >> >>> Did not get my hands on the spec yet, but just firing random thoughts. >>> This multi-link support sounds a bit like bonding. Could that be >>> leveraged for wireless? I wonder why there is a need for a non-netdev >>> interface. Does networking layer need to be aware of the multi-link >>> for scheduling traffic to it? Is there one driver per multi-link or >>> per radio? >> >> The following is what the Bonding driver / interface does for the >> multiple network interfaces. >> 1. Bonding driver aggregates multiple network interfaces into a single >> logical bonded interface. >> 2. Each network interface is called as a slave in the bonding driver. >> 3. It’s the Bonding driver that schedules the traffic across these >> slaves. >> 4. Bonding interface operates on one of the following modes ( >> mentioning for a quick reference ). >> balance-rr : Round-robin policy: Transmit packets in sequential >> order from the first available slave through the last. >> active-backup : Only one slave in the bond is active. A >> different slave becomes active if, and only if, the active slave >> fails. >> balance-xor : Transmit based on the selected transmit hash policy. >> balance-tlb : channel bonding that does not require any special >> switch support. The outgoing traffic is distributed according to the >> current load >> balance-alb : includes balance-tlb plus receive load balancing. >> 5. With the above modes, the scheduling of the traffic is determined >> with in the kernel / bonding driver and have the host driver / >> firmware follow it. >> >> The following are the factors for not considering the MLO Link as a >> bonding interface and further to propose this RFC >> (new NL80211_IF_TYPE -> NL80211_IFTYPE_MLO_LINK_DEVICE). >> >> 1. For MLO, our intention is to allow the traffic scheduling (among >> the MLO links) to be closer to the lower layers in >> the driver/firmware, etc, unlike the bonding driver where >> kernel schedules the traffic. >> 2. If MLO Link has to use a bonding interface, each MLO link has to be >> associated with a network interface and thus each >> of the MLO link has to be of NL80211_IF_TYPE -> >> NL80211_IFTYPE_STATION. >> 3. This further means that NL80211_CONNECT / NL80211_ASSOCIATE needs >> to get triggered on each of this MLO Link of the >> MLO connection. >> 4. Our intention is to consider the MLO station as a single network >> interface . More specifically, have a single >> NL80211_CONNECT / NL80211_CMD_ASSOCIATE triggered for each MLO >> connection ( MLD + MLO Links). >> 5. The reason we had to introduce a new NL80211_IF_TYPE -> >> NL80211_IFTYPE_MLO_LINK_DEVICE is to have the corresponding >> link connection specific information ( e.g., Connection State, >> Connected BSS Info, Connection Frequency/properties, etc), >> for each wdev / MLO Link and at the same time have a single >> connect / association request to the driver / AP. >> 6. Further, these NL80211_IFTYPE_MLO_LINK_DEVICE link devices shall >> represent an MLO Link and attribute to a network interface ( MLD ) of >> an >> MLO connection. >> 7. The current proposal to introduce a new NL80211_IF_TYPE should >> support the architectures of MLO links across the multiple wiphy >> interfaces or on the same wiphy interface. These wiphy >> interfaces can be from different drivers too. >> >> Please review the above. >> >>> >>> [...] >>> >>>>> struct sk_buff *msg; >>>>> void *hdr; >>>>> + struct nlattr *nested, *nested_mlo_links; >>>>> + struct cfg80211_mlo_link_device_params *mlo_link; >>>>> + int i = 0; >>>>> msg = nlmsg_new(100 + cr->req_ie_len + cr->resp_ie_len + >>>>> cr->fils.kek_len + cr->fils.pmk_len + >>>>> - (cr->fils.pmkid ? WLAN_PMKID_LEN : 0), gfp); >>>>> + (cr->fils.pmkid ? WLAN_PMKID_LEN : 0) + >>>>> + (cr->n_mlo_links ? cr->n_mlo_links * 32 : 0), gfp); >>>> >>>> 32 probably should be some NLA_SIZE or something constant? >>> >>> Probably sizeof(*mlo_link) ? >>> >>>> There's also no point in the ternary operator since 0 * 32 is 0 :) >>>> >>>>> /* Consumes bss object one way or another */ >>>>> @@ -833,7 +849,9 @@ void cfg80211_connect_done(struct net_device *dev, >>>>> ev = kzalloc(sizeof(*ev) + (params->bssid ? ETH_ALEN : 0) + >>>>> params->req_ie_len + params->resp_ie_len + >>>>> params->fils.kek_len + params->fils.pmk_len + >>>>> - (params->fils.pmkid ? WLAN_PMKID_LEN : 0), gfp); >>>>> + (params->fils.pmkid ? WLAN_PMKID_LEN : 0) + >>>>> + (params->n_mlo_links ? params->n_mlo_links * >>>>> + sizeof(struct cfg80211_mlo_link_device_params) : 0), >>>>> gfp); >>>> >>>> same here, no need for the ternary >>>> >>>> >>>> It feels strangely asymmetric to have stop and no start ... but I guess >>>> that's the part where I need to think about it and look a bit at how it >>>> all works :) >>> >>> Had the same feeling in my gutt (wherever that is ;-) >> >> Sure. Will take this point. In fact, this was documented in the commit >> message to consider the start (say start_mlo_link), but do not want >> the drivers to depend on this trigger for starting the MLO link. >> For example, the host drivers with SME can as well start the MLO Link >> after getting the Assoc response for MLO links from the AP. >> >> >>> >>> Regards, >>> Arend > > Hi, > > Can you please provide your comments on the proposal. > We wanted to hear your feedback on the following points. > > Represent MLO link of an MLO connection by a wdev of type > NL80211_IFTYPE_MLO_LINK_DEVICE. > MLO link wdev does not have an active netdev associated to it but will > be similar to that of NL80211_IFTYPE_STATION, w.r.t maintaining link’s > connection information ( connected channel , BSSID, etc). > MLD interface of an MLO connection will be a station interface > (NL80211_IFTYPE_STATION wdev) This station interface shall link the > wdev’s of all the MLO link wdev’s part of the MLO connection. Cfg80211 > layer shall link all such wdev’s. > Such MLO Link wdev’s shall be part of the same wiphy or different wiphy > (if host driver's register a single wiphy for each supported band/MAC/PHY). > MLO link wdev (NL80211_IFTYPE_MLO_LINK_DEVICE) is created by the user > space prior the MLO connection. From your explanation earlier it makes more sense to me now. > User space can as well change the interface type among > NL80211_IFTYPE_STATION wdev To NL80211_IFTYPE_MLO_LINK_DEVICE wdev. To > support the use case where an existing STA wdev can change to a MLO wdev > and vice versa. This seems complicated especially for the "vice versa" scenario where wdevs may be linked to it across different wiphy instances. btw. would that also mean different drivers. I suspect it does, right? Your explanation seems to focus on the station side of the MLO link, but I think on the AP side one would also setup a MLO link. Would the MLD interface be an AP interface in that case? Actually, if I am not too confused here then what you call an "MLO link" device is called MLD in the spec.: """ multi-link device (MLD): A device that is a logical entity and has more than one affiliated station (STA) and has a single medium access control (MAC) service access point (SAP) to logical link control (LLC), which includes one MAC data service. """ The spec refers to AP MLD and non-AP MLD. Regards, Arend -- This electronic communication and the information and any files transmitted with it, or attached to it, are confidential and are intended solely for the use of the individual or entity to whom it is addressed and may contain information that is confidential, legally privileged, protected by privacy laws, or otherwise restricted from disclosure to anyone else. If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient, you are hereby notified that any use, copying, distributing, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you received this e-mail in error, please return the e-mail to the sender, delete it from your computer, and destroy any printed copy of it.
On 2021-02-09 21:12, Arend Van Spriel wrote: > On 2/9/2021 3:48 PM, usdutt@codeaurora.org wrote: >> On 2020-12-23 21:59, usdutt@codeaurora.org wrote: >>> On 2020-12-14 14:55, Arend van Spriel wrote: >>>> On 09-12-2020 16:36, Johannes Berg wrote: >>>>> Hi, >>>>> >>>>>> Multi-link support is introduced in 802.11be specification. >>>>> [...] >>>>> >>>>> I'll definitely have to take a closer look at this and the spec and >>>>> think about it - but a couple of quick comments below. >>> >>> Thanks for your comments. Please allow me to address your comments in >>> the subsequent patches. >>> Our main intention through this RFC is to get the view on the >>> proposal >>> to introduce a new NL80211_IFTYPE for an MLO Link. >>> Please suggest on this. >>> >>> >>>> Did not get my hands on the spec yet, but just firing random >>>> thoughts. >>>> This multi-link support sounds a bit like bonding. Could that be >>>> leveraged for wireless? I wonder why there is a need for a >>>> non-netdev >>>> interface. Does networking layer need to be aware of the multi-link >>>> for scheduling traffic to it? Is there one driver per multi-link or >>>> per radio? >>> >>> The following is what the Bonding driver / interface does for the >>> multiple network interfaces. >>> 1. Bonding driver aggregates multiple network interfaces into a >>> single >>> logical bonded interface. >>> 2. Each network interface is called as a slave in the bonding driver. >>> 3. It’s the Bonding driver that schedules the traffic across these >>> slaves. >>> 4. Bonding interface operates on one of the following modes ( >>> mentioning for a quick reference ). >>> balance-rr : Round-robin policy: Transmit packets in >>> sequential >>> order from the first available slave through the last. >>> active-backup : Only one slave in the bond is active. A >>> different slave becomes active if, and only if, the active slave >>> fails. >>> balance-xor : Transmit based on the selected transmit hash >>> policy. >>> balance-tlb : channel bonding that does not require any >>> special >>> switch support. The outgoing traffic is distributed according to the >>> current load >>> balance-alb : includes balance-tlb plus receive load >>> balancing. >>> 5. With the above modes, the scheduling of the traffic is determined >>> with in the kernel / bonding driver and have the host driver / >>> firmware follow it. >>> >>> The following are the factors for not considering the MLO Link as a >>> bonding interface and further to propose this RFC >>> (new NL80211_IF_TYPE -> NL80211_IFTYPE_MLO_LINK_DEVICE). >>> >>> 1. For MLO, our intention is to allow the traffic scheduling (among >>> the MLO links) to be closer to the lower layers in >>> the driver/firmware, etc, unlike the bonding driver where >>> kernel schedules the traffic. >>> 2. If MLO Link has to use a bonding interface, each MLO link has to >>> be >>> associated with a network interface and thus each >>> of the MLO link has to be of NL80211_IF_TYPE -> >>> NL80211_IFTYPE_STATION. >>> 3. This further means that NL80211_CONNECT / NL80211_ASSOCIATE needs >>> to get triggered on each of this MLO Link of the >>> MLO connection. >>> 4. Our intention is to consider the MLO station as a single network >>> interface . More specifically, have a single >>> NL80211_CONNECT / NL80211_CMD_ASSOCIATE triggered for each >>> MLO >>> connection ( MLD + MLO Links). >>> 5. The reason we had to introduce a new NL80211_IF_TYPE -> >>> NL80211_IFTYPE_MLO_LINK_DEVICE is to have the corresponding >>> link connection specific information ( e.g., Connection State, >>> Connected BSS Info, Connection Frequency/properties, etc), >>> for each wdev / MLO Link and at the same time have a single >>> connect / association request to the driver / AP. >>> 6. Further, these NL80211_IFTYPE_MLO_LINK_DEVICE link devices shall >>> represent an MLO Link and attribute to a network interface ( MLD ) of >>> an >>> MLO connection. >>> 7. The current proposal to introduce a new NL80211_IF_TYPE should >>> support the architectures of MLO links across the multiple wiphy >>> interfaces or on the same wiphy interface. These wiphy >>> interfaces can be from different drivers too. >>> >>> Please review the above. >>> >>>> >>>> [...] >>>> >>>>>> struct sk_buff *msg; >>>>>> void *hdr; >>>>>> + struct nlattr *nested, *nested_mlo_links; >>>>>> + struct cfg80211_mlo_link_device_params *mlo_link; >>>>>> + int i = 0; >>>>>> msg = nlmsg_new(100 + cr->req_ie_len + cr->resp_ie_len + >>>>>> cr->fils.kek_len + cr->fils.pmk_len + >>>>>> - (cr->fils.pmkid ? WLAN_PMKID_LEN : 0), gfp); >>>>>> + (cr->fils.pmkid ? WLAN_PMKID_LEN : 0) + >>>>>> + (cr->n_mlo_links ? cr->n_mlo_links * 32 : 0), gfp); >>>>> >>>>> 32 probably should be some NLA_SIZE or something constant? >>>> >>>> Probably sizeof(*mlo_link) ? >>>> >>>>> There's also no point in the ternary operator since 0 * 32 is 0 :) >>>>> >>>>>> /* Consumes bss object one way or another */ >>>>>> @@ -833,7 +849,9 @@ void cfg80211_connect_done(struct net_device >>>>>> *dev, >>>>>> ev = kzalloc(sizeof(*ev) + (params->bssid ? ETH_ALEN : 0) + >>>>>> params->req_ie_len + params->resp_ie_len + >>>>>> params->fils.kek_len + params->fils.pmk_len + >>>>>> - (params->fils.pmkid ? WLAN_PMKID_LEN : 0), gfp); >>>>>> + (params->fils.pmkid ? WLAN_PMKID_LEN : 0) + >>>>>> + (params->n_mlo_links ? params->n_mlo_links * >>>>>> + sizeof(struct cfg80211_mlo_link_device_params) : >>>>>> 0), gfp); >>>>> >>>>> same here, no need for the ternary >>>>> >>>>> >>>>> It feels strangely asymmetric to have stop and no start ... but I >>>>> guess >>>>> that's the part where I need to think about it and look a bit at >>>>> how it >>>>> all works :) >>>> >>>> Had the same feeling in my gutt (wherever that is ;-) >>> >>> Sure. Will take this point. In fact, this was documented in the >>> commit >>> message to consider the start (say start_mlo_link), but do not want >>> the drivers to depend on this trigger for starting the MLO link. >>> For example, the host drivers with SME can as well start the MLO Link >>> after getting the Assoc response for MLO links from the AP. >>> >>> >>>> >>>> Regards, >>>> Arend >> >> Hi, >> >> Can you please provide your comments on the proposal. >> We wanted to hear your feedback on the following points. >> >> Represent MLO link of an MLO connection by a wdev of type >> NL80211_IFTYPE_MLO_LINK_DEVICE. >> MLO link wdev does not have an active netdev associated to it but will >> be similar to that of NL80211_IFTYPE_STATION, w.r.t maintaining link’s >> connection information ( connected channel , BSSID, etc). >> MLD interface of an MLO connection will be a station interface >> (NL80211_IFTYPE_STATION wdev) This station interface shall link the >> wdev’s of all the MLO link wdev’s part of the MLO connection. Cfg80211 >> layer shall link all such wdev’s. >> Such MLO Link wdev’s shall be part of the same wiphy or different >> wiphy (if host driver's register a single wiphy for each supported >> band/MAC/PHY). >> MLO link wdev (NL80211_IFTYPE_MLO_LINK_DEVICE) is created by the user >> space prior the MLO connection. > > From your explanation earlier it makes more sense to me now. > >> User space can as well change the interface type among >> NL80211_IFTYPE_STATION wdev To NL80211_IFTYPE_MLO_LINK_DEVICE wdev. To >> support the use case where an existing STA wdev can change to a MLO >> wdev and vice versa. > > This seems complicated especially for the "vice versa" scenario where > wdevs may be linked to it across different wiphy instances. btw. would > that also mean different drivers. I suspect it does, right? The switch / change interface among the STA or MLO Link shall happen only in the disconnected state. At this point, (in the disconnected state) these MLO Link wdev’s are not linked to the STA interface ( either on the same / different wiphy ). These shall be linked after the Association to an MLO AP. The intention here is to have the wdev in the right mode ( STA or MLO Link ) before the connect / Association is triggered. This wdev is put in to a MLO_LINK_DEVICE, before the connect / association is triggered on the respective MLD (IFTYPE_STA) interface for an MLO connection. This wdev is put in the IFTYPE_STA mode, before triggering a connect / association on this interface. This should be applicable for different drivers too. Please let us know if there are any caveats in this design > > Your explanation seems to focus on the station side of the MLO link, > but I think on the AP side one would also setup a MLO link. Would the > MLD interface be an AP interface in that case? Yes. The wdev - NL80211_IFTYPE_MLO_LINK_DEVICE only represents a “MLO Link” on the non-AP MLD.This would not be required for an AP MLO. The following explains our design for AP. For AP , NL80211_IFTYPE_AP wdev shall represent both – AP instance for non-MLO / legacy client and an MLO link for AP-MLD. To be specific, For a 2 link AP MLD , there will be 2 NL80211_IFTYPE_AP wdev's created. Both these wdev’s shall represent the MLO Link for an AP-MLD and each also represent an AP instance for the non-MLO / legacy client’s to connect. MLO Link MAC address will be the MAC address of respective AP’s (netdev/wdev). A non-MLO client can connect to the respective AP instance, while the non AP MLD connect’ s to the MLD AP by authenticating on either of the AP (links). > Actually, if I am not too confused here then what you call an "MLO > link" device is called MLD in the spec.: > > """ > multi-link device (MLD): A device that is a logical entity and has > more than one affiliated station (STA) and has a single medium access > control (MAC) service access point (SAP) to logical link control > (LLC), which includes one MAC data service. > """ > > The spec refers to AP MLD and non-AP MLD. “MLO link” here refers to the link which is defined as the connectivity between an AP-STA and the non-AP STA. A multi-link device (MLD) consists of more than one STAs. An AP-MLD consists of more than one AP STAs, and a non-AP MLD consists of one or more non-AP STAs. There can be multiple links between the AP and non-AP STAs for an MLD and each of these links are referred by “MLO link”. Currently , NL80211_IFTYPE_STATION wdev represents the non MLD client / legacy connection to the non-MLD AP. With this proposal, We plan to extend this for MLO too, by reusing this NL80211_IFTYPE_STATION wdev to represent the “association link” for an MLD connection and new wdev type - NL80211_IFTYPE_MLO_LINK_DEVICE to represent the additional links of the same MLD connection. (e.g., These MLO Links represent multiple links – Link2, link3 and Link1 of MLD connection from “Example of multi-link setup” – Figure 35-2 of D0.2 11be spec) Regards, Sunil
Hi, Sorry for being so late on the thread. Took me far longer than I wanted to get into looking at MLO at all. > The switch / change interface among the STA or MLO Link shall happen > only in the disconnected state. > At this point, (in the disconnected state) these MLO Link wdev’s are not > linked to the STA interface ( either on the same / different wiphy ). > These shall be linked after the Association to an MLO AP. > The intention here is to have the wdev in the right mode ( STA or MLO > Link ) before the connect / Association is triggered. > This wdev is put in to a MLO_LINK_DEVICE, before the connect / > association is triggered on the respective MLD (IFTYPE_STA) interface > for an MLO connection. > This wdev is put in the IFTYPE_STA mode, before triggering a connect / > association on this interface. > > This should be applicable for different drivers too. > > Please let us know if there are any caveats in this design Just to summarize, to see if I'm understanding it correctly. You're basically saying that on the client side 1) the NL80211_IFTYPE_STATION interfaces becomes the MLD with whatever MAC address it may have, and does not maintain its "own" association to an AP; 2) instead, a number of NL80211_IFTYPE_MLO_LINK (let's drop the DEVICE it's long enough) are added to it, with appropriate link addresses selected for them; 3) this configuration can only happen while none of them are connected. Right? Wrt. MAC addresses, I suppose from our pure software POV the _MLO_LINK could share a MAC address with the MLD (_STATION), although I hear that there's still a discussion right now on MLD-addressed and link-addressed management frames, so I think we need to wait until we know that for sure. A couple of questions: 1) How do we present this to userspace, is that it? Wouldn't the _STATION (MLD) interface ideally still have *some* visible wireless state, and show which network it's connected to? It might be very awkward to require all userspace tools to be updated to know about and query for _MLO_LINKs. Obviously, wpa_supplicant needs to be aware of these and can handle it just fine, so I'm more concerned about other userspace. After all, people still use tools built on wireless extensions 2) In some ways related to 1), but in other ways also not - perhaps we need to anticipate that some devices will want to handle MLO link decisions in firmware? I haven't thought about this much at all, but if we require separate MLO_LINK type wdevs for each link that might be tricky? 3) I keep thinking about moving much "associated" state into the STA struct we maintain in the kernel, and actually maintaining the *links* only as "multiple associations". This also gets tricky with the link MAC addresses in a way, though that could be handled. It might also be an easier way to manage some of that state problem from my question 1)? Any thoughts on this? I'm definitely not saying this would be easy, but would it simplify things regarding the userspace APIs and the offload question in 2)? Any other designs than the MLO_LINK wdev that you have considered and discarded, and if so for which reasons? > The wdev - NL80211_IFTYPE_MLO_LINK_DEVICE only represents a “MLO Link” > on the non-AP MLD.This would not be required for an AP MLO. FWIW, I don't buy the part about this not being required for an AP MLD. > The following explains our design for AP. > For AP , NL80211_IFTYPE_AP wdev shall represent both – AP instance for > non-MLO / legacy client and an MLO link for AP-MLD. > To be specific, For a 2 link AP MLD , there will be 2 NL80211_IFTYPE_AP > wdev's created. This will not work if there's a need (and possibly spec requirement) to have an MLD address that's different from *all* the link addresses. It will also be difficult to manage that one of the AP interfaces would have to be defacto the MLD, but (at least in theory) any one of the AP interfaces could be removed for 'degraded' operation. I suspect will also not work right if you want to have AP_VLAN on the AP MLD. IMHO it'd be better for things to be symmetric like you suggest for the client side. Now, I can see the need for legacy interoperability, but then it seems it would probably be better to do this the other way around and declare a new AP_MLD interface type (with a netdev) that doesn't maintain its own beacons etc. but just has its own MAC address (the AP MLD address) and bubbles up the data frames exchanged on the MLD. > Both these wdev’s shall represent the MLO Link for an AP-MLD and each > also represent an AP instance for the non-MLO / legacy client’s to > connect. Yeah, don't think that works, see above. > MLO Link MAC address will be the MAC address of respective AP’s > (netdev/wdev). Same here. Note that there may be a requirement, or at least a very strong incentive, to have an MLD address different from all the links, and we cannot preclude that in the design even if it doesn't become a requirement. > With this proposal, We plan to extend this for MLO too, by reusing this > NL80211_IFTYPE_STATION wdev to represent the “association link” for an > MLD connection > and new wdev type - NL80211_IFTYPE_MLO_LINK_DEVICE to represent the > additional links of the same MLD connection. Wait, ok, this is *not* how I understood the proposal above. Again, I don't think this works for the same reasons I outlined on the AP case - symmetry, links coming and going, and MAC addressing. johannes
Hi , Thanks for your response. >> The switch / change interface among the STA or MLO Link shall happen >> only in the disconnected state. >> At this point, (in the disconnected state) these MLO Link wdev’s are >> not >> linked to the STA interface ( either on the same / different wiphy ). >> These shall be linked after the Association to an MLO AP. >> The intention here is to have the wdev in the right mode ( STA or MLO >> Link ) before the connect / Association is triggered. >> This wdev is put in to a MLO_LINK_DEVICE, before the connect / >> association is triggered on the respective MLD (IFTYPE_STA) interface >> for an MLO connection. >> This wdev is put in the IFTYPE_STA mode, before triggering a connect / >> association on this interface. >> >> This should be applicable for different drivers too. >> >> Please let us know if there are any caveats in this design > > > Just to summarize, to see if I'm understanding it correctly. > > You're basically saying that on the client side > > 1) the NL80211_IFTYPE_STATION interfaces becomes the MLD with whatever > MAC address it may have, and does not maintain its "own" > association > to an AP; > 2) instead, a number of NL80211_IFTYPE_MLO_LINK (let's drop the DEVICE > it's long enough) are added to it, with appropriate link addresses > selected for them; > 3) this configuration can only happen while none of them are > connected. > > Right? No . Our intention was the NL80211_IFTYPE_STATION interface to also represent the MLD + MLO Link while the NL80211_IFTYPE_MLO_LINK wdevs represents other MLO Links of an MLO connection. This MLO_LINK wdev will not have its netdev. The IFTYPE_STATION wdev shall link all such MLO_LINK’s which are part of the same MLD connection. That way , there will be a single netdev interface exposed to the applications for the data transfer and these MLO_LINK wdevs along with NL80211_IFTYPE_STATION wdev represent the corresponding connection/link status with the MLD AP. Please note that in this case the NL80211_IFTYPE_STATION Acts as both the MLD and one of the MLO Link’s. > > Wrt. MAC addresses, I suppose from our pure software POV the _MLO_LINK > could share a MAC address with the MLD (_STATION), although I hear that > there's still a discussion right now on MLD-addressed and > link-addressed > management frames, so I think we need to wait until we know that for > sure. > > A couple of questions: > > 1) How do we present this to userspace, is that it? Wouldn't the > _STATION (MLD) interface ideally still have *some* visible wireless > state, and show which network it's connected to? It might be very > awkward to require all userspace tools to be updated to know about > and query for _MLO_LINKs. > > Obviously, wpa_supplicant needs to be aware of these and can handle > it just fine, so I'm more concerned about other userspace. After > all, people still use tools built on wireless extensions As I have mentioned above , the _STATION is both the MLD and one of the MLO Links. This shall still have the connected state with its MLO Link representing the connection info with the AP. The other MLO Link of a 2 Link MLO connection to the AP (for example) is represented by the _MLO_LINK wdev. Userspace tools can still see this _STATION as both the MLD and non MLD station interface connection. For an MLD connection this _STATION interface will also link with the corresponding _MLO_LINK wdev’s and thus any MLO aware user applications can as well get the connection stats of the corresponding MLO Links along with _STATION link through the _STATION interface. > > 2) In some ways related to 1), but in other ways also not - perhaps we > need to anticipate that some devices will want to handle MLO link > decisions in firmware? I haven't thought about this much at all, > but > if we require separate MLO_LINK type wdevs for each link that might > be tricky? Are you saying that these devices want to totally handle the MLO link establishments with in the firmware ? Let me take an example here. I have taken a 2 link MLO for a reference. Such devices want to still represent the station interface with NL80211_IFTYPE_STATION to the cfg80211 and create multiple links with in the firmware ? Technically, the _STATION interface here is connected to 2 BSSID’s . Can I know What would _STATION(wdev)->current_bss represent here ? > 3) I keep thinking about moving much "associated" state into the STA > struct we maintain in the kernel, and actually maintaining the > *links* only as "multiple associations". This also gets tricky with > the link MAC addresses in a way, though that could be handled. It > might also be an easier way to manage some of that state problem > from my question 1)? > > Any thoughts on this? I'm definitely not saying this would be easy, > but would it simplify things regarding the userspace APIs and the > offload question in 2)? Can I know how these “multiple associations” would be represented as to the user space ? With your proposal above, the userspace applications shall still see a single NL80211_IFTYPE_STATION and multiple links are maintained within this wdev ? Fine , this would work as long as these links are with in the same wiphy. Let me present the two use cases we considered MLO for. 1)single wiphy to represent multiple bands on which the MLO Links can be formed : In this case the _STATION interface would be on a single wiphy and yeah your proposal would hold good. We initially thought on similar lines. Thanks. 2) single wiphy for each supported band: Say there are two wiphy’s here , each representing the respective bands 2G and 5G/6G. In this specific case, the non MLO solution had two _STATION interfaces connecting to the AP’s on respective bands. We are aiming to enhance this design for MLO . In this case, the MLO Links spawn across different wiphy’s and at the same time has to be backward compatible for the non MLO connection ( dual STA ) . To suite the above two use cases , we proposed the introduction of _MLO_LINK wdev and the _STATION interface to link all the _MLO_LINK wdev’s that are part of the respective MLD connection. Thus, a _STATION wdev can be changed to the _MLO_LINK wdev and vice versa to have both the MLO and non MLO connection (Dual STA). > Any other designs than the MLO_LINK wdev that you have considered > and discarded, and if so for which reasons? > > >> The wdev - NL80211_IFTYPE_MLO_LINK_DEVICE only represents a “MLO Link” >> on the non-AP MLD.This would not be required for an AP MLO. > > FWIW, I don't buy the part about this not being required for an AP MLD. > >> The following explains our design for AP. >> For AP , NL80211_IFTYPE_AP wdev shall represent both – AP instance >> for >> non-MLO / legacy client and an MLO link for AP-MLD. >> To be specific, For a 2 link AP MLD , there will be 2 >> NL80211_IFTYPE_AP >> wdev's created. > > This will not work if there's a need (and possibly spec requirement) to > have an MLD address that's different from *all* the link addresses. It > will also be difficult to manage that one of the AP interfaces would > have to be defacto the MLD, but (at least in theory) any one of the AP > interfaces could be removed for 'degraded' operation. > > I suspect will also not work right if you want to have AP_VLAN on the > AP > MLD. > > IMHO it'd be better for things to be symmetric like you suggest for the > client side. > > Now, I can see the need for legacy interoperability, but then it seems > it would probably be better to do this the other way around and declare > a new AP_MLD interface type (with a netdev) that doesn't maintain its > own beacons etc. but just has its own MAC address (the AP MLD address) > and bubbles up the data frames exchanged on the MLD. OK. A new AP_MLD with a netdev to represent the MLD. I guess this is to only facilitate the need for a different MLD address over the MLO link addresses? Taking an example , A 2 MLO AP would have the following . Please correct me . Two _ IFTYPE_AP wdev’s , representing a Link for an MLD AP and an AP instance for a non MLD AP ( for the legacy clients to connect ). These two wdev’s maintain their own beacon’s and do have the corresponding netdev’s. A new AP_MLD with it’s own netdev but doesn’t maintain it’s beacon. The two _IFTYPE_AP wdev’s, representing the link shall point to this AP_MLD interface for the MLD address ? We had seen some concerns on this model and please allow me to get back to you as early as possible. Regards, Sunil
On 2021-02-12 22:33, usdutt@codeaurora.org wrote: > Hi , > Thanks for your response. > >>> The switch / change interface among the STA or MLO Link shall happen >>> only in the disconnected state. >>> At this point, (in the disconnected state) these MLO Link wdev’s are >>> not >>> linked to the STA interface ( either on the same / different wiphy ). >>> These shall be linked after the Association to an MLO AP. >>> The intention here is to have the wdev in the right mode ( STA or MLO >>> Link ) before the connect / Association is triggered. >>> This wdev is put in to a MLO_LINK_DEVICE, before the connect / >>> association is triggered on the respective MLD (IFTYPE_STA) interface >>> for an MLO connection. >>> This wdev is put in the IFTYPE_STA mode, before triggering a connect >>> / >>> association on this interface. >>> >>> This should be applicable for different drivers too. >>> >>> Please let us know if there are any caveats in this design >> >> >> Just to summarize, to see if I'm understanding it correctly. >> >> You're basically saying that on the client side >> >> 1) the NL80211_IFTYPE_STATION interfaces becomes the MLD with >> whatever >> MAC address it may have, and does not maintain its "own" >> association >> to an AP; >> 2) instead, a number of NL80211_IFTYPE_MLO_LINK (let's drop the >> DEVICE >> it's long enough) are added to it, with appropriate link addresses >> selected for them; >> 3) this configuration can only happen while none of them are >> connected. >> >> Right? > > No . Our intention was the NL80211_IFTYPE_STATION interface to also > represent > the MLD + MLO Link while the NL80211_IFTYPE_MLO_LINK wdevs represents > other MLO > Links of an MLO connection. > This MLO_LINK wdev will not have its netdev. The IFTYPE_STATION wdev > shall > link all such MLO_LINK’s which are part of the same MLD connection. > That way , there will be a single netdev interface exposed to the > applications > for the data transfer and these MLO_LINK wdevs along with > NL80211_IFTYPE_STATION > wdev represent the corresponding connection/link status with the MLD > AP. > Please note that in this case the NL80211_IFTYPE_STATION Acts as both > the MLD > and one of the MLO Link’s. > >> >> Wrt. MAC addresses, I suppose from our pure software POV the _MLO_LINK >> could share a MAC address with the MLD (_STATION), although I hear >> that >> there's still a discussion right now on MLD-addressed and >> link-addressed >> management frames, so I think we need to wait until we know that for >> sure. >> >> A couple of questions: >> >> 1) How do we present this to userspace, is that it? Wouldn't the >> _STATION (MLD) interface ideally still have *some* visible >> wireless >> state, and show which network it's connected to? It might be very >> awkward to require all userspace tools to be updated to know about >> and query for _MLO_LINKs. >> >> Obviously, wpa_supplicant needs to be aware of these and can >> handle >> it just fine, so I'm more concerned about other userspace. After >> all, people still use tools built on wireless extensions > > As I have mentioned above , the _STATION is both the MLD and one of the > MLO Links. > This shall still have the connected state with its MLO Link > representing > the connection info with the AP. > The other MLO Link of a 2 Link MLO connection to the AP (for example) > is > represented by the _MLO_LINK wdev. > Userspace tools can still see this _STATION as both the MLD and non MLD > station interface connection. > For an MLD connection this _STATION interface will also link with the > corresponding _MLO_LINK wdev’s and thus any > MLO aware user applications can as well get the connection stats of the > corresponding MLO Links along with _STATION link through the _STATION > interface. > >> >> 2) In some ways related to 1), but in other ways also not - perhaps >> we >> need to anticipate that some devices will want to handle MLO link >> decisions in firmware? I haven't thought about this much at all, >> but >> if we require separate MLO_LINK type wdevs for each link that >> might >> be tricky? > > Are you saying that these devices want to totally handle the MLO link > establishments with in the firmware ? > Let me take an example here. I have taken a 2 link MLO for a > reference. > Such devices want to still represent the station interface with > NL80211_IFTYPE_STATION to the cfg80211 and create multiple links with > in > the firmware ? > Technically, the _STATION interface here is connected to 2 BSSID’s . > Can I know What would _STATION(wdev)->current_bss represent here ? > > >> 3) I keep thinking about moving much "associated" state into the STA >> struct we maintain in the kernel, and actually maintaining the >> *links* only as "multiple associations". This also gets tricky >> with >> the link MAC addresses in a way, though that could be handled. It >> might also be an easier way to manage some of that state problem >> from my question 1)? >> >> Any thoughts on this? I'm definitely not saying this would be >> easy, >> but would it simplify things regarding the userspace APIs and the >> offload question in 2)? > > Can I know how these “multiple associations” would be represented as to > the user space ? > With your proposal above, the userspace applications shall still see a > single NL80211_IFTYPE_STATION and multiple links are maintained within > this > wdev ? > Fine , this would work as long as these links are with in the same > wiphy. > > Let me present the two use cases we considered MLO for. > > 1)single wiphy to represent multiple bands on which the MLO Links can > be formed : > In this case the _STATION interface would be on a single wiphy and yeah > your > proposal would hold good. We initially thought on similar lines. > Thanks. > 2) single wiphy for each supported band: Say there are two wiphy’s here > , each > representing the respective bands 2G and 5G/6G. In this specific case, > the non > MLO solution had two _STATION interfaces connecting to the AP’s on > respective bands. > > We are aiming to enhance this design for MLO . In this case, the MLO > Links spawn > across different wiphy’s and at the same time has to be backward > compatible for > the non MLO connection ( dual STA ) . > To suite the above two use cases , we proposed the introduction of > _MLO_LINK wdev > and the _STATION interface to link all the _MLO_LINK wdev’s that are > part of the > respective MLD connection. > Thus, a _STATION wdev can be changed to the _MLO_LINK wdev and vice > versa to have > both the MLO and non MLO connection (Dual STA). > >> Any other designs than the MLO_LINK wdev that you have considered >> and discarded, and if so for which reasons? >> >> >>> The wdev - NL80211_IFTYPE_MLO_LINK_DEVICE only represents a “MLO >>> Link” >>> on the non-AP MLD.This would not be required for an AP MLO. >> >> FWIW, I don't buy the part about this not being required for an AP >> MLD. >> >>> The following explains our design for AP. >>> For AP , NL80211_IFTYPE_AP wdev shall represent both – AP instance >>> for >>> non-MLO / legacy client and an MLO link for AP-MLD. >>> To be specific, For a 2 link AP MLD , there will be 2 >>> NL80211_IFTYPE_AP >>> wdev's created. >> >> This will not work if there's a need (and possibly spec requirement) >> to >> have an MLD address that's different from *all* the link addresses. It >> will also be difficult to manage that one of the AP interfaces would >> have to be defacto the MLD, but (at least in theory) any one of the AP >> interfaces could be removed for 'degraded' operation. >> >> I suspect will also not work right if you want to have AP_VLAN on the >> AP >> MLD. >> >> IMHO it'd be better for things to be symmetric like you suggest for >> the >> client side. >> >> Now, I can see the need for legacy interoperability, but then it seems >> it would probably be better to do this the other way around and >> declare >> a new AP_MLD interface type (with a netdev) that doesn't maintain its >> own beacons etc. but just has its own MAC address (the AP MLD address) >> and bubbles up the data frames exchanged on the MLD. > > OK. A new AP_MLD with a netdev to represent the MLD. I guess this is > to > only facilitate the need for a different MLD address over the MLO link > addresses? > > Taking an example , A 2 MLO AP would have the following . Please > correct me . > Two _ IFTYPE_AP wdev’s , representing a Link for an MLD AP and an AP > instance > for a non MLD AP ( for the legacy clients to connect ). These two > wdev’s maintain > their own beacon’s and do have the corresponding netdev’s. > A new AP_MLD with it’s own netdev but doesn’t maintain it’s beacon. The > two > _IFTYPE_AP wdev’s, representing the link shall point to this AP_MLD > interface > for the MLD address ? > > We had seen some concerns on this model and please allow me to get back > to you > as early as possible. Continuing with this 2 link MLO example further, our thought is to bridge the 2 netdev’s associated with each MLO Link ( MLD AP ) / AP instance ( non MLD AP ). Thus, the bridge interface shall represent the network interface for the non MLD & MLD AP to the network stack. Adding further, it is this bridge interface that gets routed over the network stack and thus the destination / source MAC address of the IP frames from / to non MLO / MLO clients associated to the AP would be the bridge MAC address. If this is agreed, then in the above topology the MLD MAC Address / netdev is not used and this MAC address is used as the destination MAC only for certain frames ( EAPOL frames , from our study till now ) . So, we were debating if we need a separate netdev to represent the MLD MAC address. Would it be needed for RX / TX of EAPOL frames also from the hostapd / user space ? IMHO No, as these frames could as well be exchanged over the NL interface , isn’t ? Another thought is to just consider this MLD MAC address as a logical entity (without associating to the netdev) which is different address from the Link addresses. That said, can this model of “AP_MLD interface type ( with a netdev ) “ made optional and left for the driver architectures to use it ( separate netdev for the MLD MAC ) ? Regards, Sunil
On 2021-02-18 22:56, usdutt@codeaurora.org wrote: > On 2021-02-12 22:33, usdutt@codeaurora.org wrote: >> Hi , >> Thanks for your response. >> >>>> The switch / change interface among the STA or MLO Link shall happen >>>> only in the disconnected state. >>>> At this point, (in the disconnected state) these MLO Link wdev’s are >>>> not >>>> linked to the STA interface ( either on the same / different wiphy >>>> ). >>>> These shall be linked after the Association to an MLO AP. >>>> The intention here is to have the wdev in the right mode ( STA or >>>> MLO >>>> Link ) before the connect / Association is triggered. >>>> This wdev is put in to a MLO_LINK_DEVICE, before the connect / >>>> association is triggered on the respective MLD (IFTYPE_STA) >>>> interface >>>> for an MLO connection. >>>> This wdev is put in the IFTYPE_STA mode, before triggering a connect >>>> / >>>> association on this interface. >>>> >>>> This should be applicable for different drivers too. >>>> >>>> Please let us know if there are any caveats in this design >>> >>> >>> Just to summarize, to see if I'm understanding it correctly. >>> >>> You're basically saying that on the client side >>> >>> 1) the NL80211_IFTYPE_STATION interfaces becomes the MLD with >>> whatever >>> MAC address it may have, and does not maintain its "own" >>> association >>> to an AP; >>> 2) instead, a number of NL80211_IFTYPE_MLO_LINK (let's drop the >>> DEVICE >>> it's long enough) are added to it, with appropriate link >>> addresses >>> selected for them; >>> 3) this configuration can only happen while none of them are >>> connected. >>> >>> Right? >> >> No . Our intention was the NL80211_IFTYPE_STATION interface to also >> represent >> the MLD + MLO Link while the NL80211_IFTYPE_MLO_LINK wdevs represents >> other MLO >> Links of an MLO connection. >> This MLO_LINK wdev will not have its netdev. The IFTYPE_STATION wdev >> shall >> link all such MLO_LINK’s which are part of the same MLD connection. >> That way , there will be a single netdev interface exposed to the >> applications >> for the data transfer and these MLO_LINK wdevs along with >> NL80211_IFTYPE_STATION >> wdev represent the corresponding connection/link status with the MLD >> AP. >> Please note that in this case the NL80211_IFTYPE_STATION Acts as both >> the MLD >> and one of the MLO Link’s. >> >>> >>> Wrt. MAC addresses, I suppose from our pure software POV the >>> _MLO_LINK >>> could share a MAC address with the MLD (_STATION), although I hear >>> that >>> there's still a discussion right now on MLD-addressed and >>> link-addressed >>> management frames, so I think we need to wait until we know that for >>> sure. >>> >>> A couple of questions: >>> >>> 1) How do we present this to userspace, is that it? Wouldn't the >>> _STATION (MLD) interface ideally still have *some* visible >>> wireless >>> state, and show which network it's connected to? It might be very >>> awkward to require all userspace tools to be updated to know >>> about >>> and query for _MLO_LINKs. >>> >>> Obviously, wpa_supplicant needs to be aware of these and can >>> handle >>> it just fine, so I'm more concerned about other userspace. After >>> all, people still use tools built on wireless extensions >> >> As I have mentioned above , the _STATION is both the MLD and one of >> the >> MLO Links. >> This shall still have the connected state with its MLO Link >> representing >> the connection info with the AP. >> The other MLO Link of a 2 Link MLO connection to the AP (for example) >> is >> represented by the _MLO_LINK wdev. >> Userspace tools can still see this _STATION as both the MLD and non >> MLD >> station interface connection. >> For an MLD connection this _STATION interface will also link with the >> corresponding _MLO_LINK wdev’s and thus any >> MLO aware user applications can as well get the connection stats of >> the >> corresponding MLO Links along with _STATION link through the _STATION >> interface. >> >>> >>> 2) In some ways related to 1), but in other ways also not - perhaps >>> we >>> need to anticipate that some devices will want to handle MLO link >>> decisions in firmware? I haven't thought about this much at all, >>> but >>> if we require separate MLO_LINK type wdevs for each link that >>> might >>> be tricky? >> >> Are you saying that these devices want to totally handle the MLO link >> establishments with in the firmware ? >> Let me take an example here. I have taken a 2 link MLO for a >> reference. >> Such devices want to still represent the station interface with >> NL80211_IFTYPE_STATION to the cfg80211 and create multiple links with >> in >> the firmware ? >> Technically, the _STATION interface here is connected to 2 BSSID’s . >> Can I know What would _STATION(wdev)->current_bss represent here ? >> >> >>> 3) I keep thinking about moving much "associated" state into the STA >>> struct we maintain in the kernel, and actually maintaining the >>> *links* only as "multiple associations". This also gets tricky >>> with >>> the link MAC addresses in a way, though that could be handled. It >>> might also be an easier way to manage some of that state problem >>> from my question 1)? >>> >>> Any thoughts on this? I'm definitely not saying this would be >>> easy, >>> but would it simplify things regarding the userspace APIs and the >>> offload question in 2)? >> >> Can I know how these “multiple associations” would be represented as >> to >> the user space ? >> With your proposal above, the userspace applications shall still see a >> single NL80211_IFTYPE_STATION and multiple links are maintained within >> this >> wdev ? >> Fine , this would work as long as these links are with in the same >> wiphy. >> >> Let me present the two use cases we considered MLO for. >> >> 1)single wiphy to represent multiple bands on which the MLO Links can >> be formed : >> In this case the _STATION interface would be on a single wiphy and >> yeah your >> proposal would hold good. We initially thought on similar lines. >> Thanks. >> 2) single wiphy for each supported band: Say there are two wiphy’s >> here , each >> representing the respective bands 2G and 5G/6G. In this specific case, >> the non >> MLO solution had two _STATION interfaces connecting to the AP’s on >> respective bands. >> >> We are aiming to enhance this design for MLO . In this case, the MLO >> Links spawn >> across different wiphy’s and at the same time has to be backward >> compatible for >> the non MLO connection ( dual STA ) . >> To suite the above two use cases , we proposed the introduction of >> _MLO_LINK wdev >> and the _STATION interface to link all the _MLO_LINK wdev’s that are >> part of the >> respective MLD connection. >> Thus, a _STATION wdev can be changed to the _MLO_LINK wdev and vice >> versa to have >> both the MLO and non MLO connection (Dual STA). >> >>> Any other designs than the MLO_LINK wdev that you have considered >>> and discarded, and if so for which reasons? >>> >>> >>>> The wdev - NL80211_IFTYPE_MLO_LINK_DEVICE only represents a “MLO >>>> Link” >>>> on the non-AP MLD.This would not be required for an AP MLO. >>> >>> FWIW, I don't buy the part about this not being required for an AP >>> MLD. >>> >>>> The following explains our design for AP. >>>> For AP , NL80211_IFTYPE_AP wdev shall represent both – AP instance >>>> for >>>> non-MLO / legacy client and an MLO link for AP-MLD. >>>> To be specific, For a 2 link AP MLD , there will be 2 >>>> NL80211_IFTYPE_AP >>>> wdev's created. >>> >>> This will not work if there's a need (and possibly spec requirement) >>> to >>> have an MLD address that's different from *all* the link addresses. >>> It >>> will also be difficult to manage that one of the AP interfaces would >>> have to be defacto the MLD, but (at least in theory) any one of the >>> AP >>> interfaces could be removed for 'degraded' operation. >>> >>> I suspect will also not work right if you want to have AP_VLAN on the >>> AP >>> MLD. >>> >>> IMHO it'd be better for things to be symmetric like you suggest for >>> the >>> client side. >>> >>> Now, I can see the need for legacy interoperability, but then it >>> seems >>> it would probably be better to do this the other way around and >>> declare >>> a new AP_MLD interface type (with a netdev) that doesn't maintain its >>> own beacons etc. but just has its own MAC address (the AP MLD >>> address) >>> and bubbles up the data frames exchanged on the MLD. >> >> OK. A new AP_MLD with a netdev to represent the MLD. I guess this is >> to >> only facilitate the need for a different MLD address over the MLO link >> addresses? >> >> Taking an example , A 2 MLO AP would have the following . Please >> correct me . >> Two _ IFTYPE_AP wdev’s , representing a Link for an MLD AP and an AP >> instance >> for a non MLD AP ( for the legacy clients to connect ). These two >> wdev’s maintain >> their own beacon’s and do have the corresponding netdev’s. >> A new AP_MLD with it’s own netdev but doesn’t maintain it’s beacon. >> The two >> _IFTYPE_AP wdev’s, representing the link shall point to this AP_MLD >> interface >> for the MLD address ? >> >> We had seen some concerns on this model and please allow me to get >> back to you >> as early as possible. > > Continuing with this 2 link MLO example further, our thought is to > bridge the > 2 netdev’s associated with each MLO Link ( MLD AP ) / AP instance ( > non MLD AP ). > Thus, the bridge interface shall represent the network interface for > the non MLD & > MLD AP to the network stack. > Adding further, it is this bridge interface that gets routed over the > network stack > and thus the destination / source MAC address of the IP frames from / > to non MLO / MLO > clients associated to the AP would be the bridge MAC address. > If this is agreed, then in the above topology the MLD MAC Address / > netdev is not used > and this MAC address is used as the destination MAC only for certain > frames > ( EAPOL frames , from our study till now ) . > So, we were debating if we need a separate netdev to represent the MLD > MAC address. > Would it be needed for RX / TX of EAPOL frames also from the hostapd / > user space ? > IMHO No, as these frames could as well be exchanged over the NL > interface , isn’t ? > > Another thought is to just consider this MLD MAC address as a logical > entity > (without associating to the netdev) which is different address from > the Link addresses. > That said, can this model of “AP_MLD interface type ( with a netdev ) > “ made optional > and left for the driver architectures to use it ( separate netdev for > the MLD MAC ) ? > > Regards, > Sunil Hi , Can you please help us review the proposal for MLO AP and STA. The following is the high level summary of MLO behavior for both the modes, based on your earlier suggestions. MLO STA ( non – AP ) 1) An MLD is represented by the NL80211_IFTYPE_STATION wdev. 2) Each MLO Link is represented by a new wdev type - NL80211_IFTYPE_MLO_LINK 3) Each MLO Link wdev represent the connection information of the respective link with the MLO AP. 4) The NL80211_IFTYPE_STATION wdev behavior would change based on if the connection is MLO vs non MLO. a) For a non MLO NL80211_IFTYPE_STATION Wdev, the current_bss (wdev) represents the current connected bss information. b) For an MLO, NL80211_IFTYPE_STATION Wdev will fetch the current_bss info from the respective NL80211_IFTYPE_MLO_LINK Wdev. 5) Thus, the NL80211_IFTYPE_STATION wdev will maintain the list of all such NL80211_IFTYPE_MLO_LINK Wdev's for an MLO station. 6) These NL80211_IFTYPE_MLO_LINK Wdev’s can be either on the same or different wiphy as that of NL80211_IFTYPE_STATION Wdev. This is to facilitate the dual band architectures, where each wiphy represents the respective band. 7) Can either of following options be considered to represent a MLD STA. Leave up to the driver architectures to use the same. a) Having a separate wdev for an MLD STA. This provides an option to set any link specific attributes ( e.g., MAC address) via MLO Link wdev while ML specific attributes can be set via MLD STA wdev b) No separate wdev / netdev representation for the MLD STA. We wanted to explore if a NL80211_IFTYPE_STATION wdev can as well act as one of the MLO Link’s. For the architectures that can support same MLO Link and MLD. This will allow driver to support the model of MLD mac being same as link mac address or different. MLO AP 1) For AP , NL80211_IFTYPE_AP wdev shall represent both – distinct AP instance (for non-MLO client associations) and an AP in AP MLD for MLO client associations. 2) The MLO Links for the AP are represented by the respective NL80211_IFTYPE_AP wdev's. 3) Can either of following options be considered to represent a MLD AP. Leave up to the driver architectures to use the same. a) A new wdev interface type NL80211_IFTYPE_MLD_AP represents the MLD for an MLO AP. This NL80211_IFTYPE_MLD_AP Shall not have its own beacon, but will have a netdev associated to it, which represents the MLD of MLO AP. b) No separate wdev / netdev representation for the MLD AP. Hostapd is aware of/derives the MLD MAC address and uses the regular MLO Link AP wdevs(any) for all the required ML mgmt and EAPOL interactions. This is for the architectures where there are no Data frames ( apart from EAPOL ) destined to MLD. The MLO Link AP’s are added to the bridge interface and data frames are forwarded via bridge, practically. This also helps in architectures where large number of virtual AP’s are the requirement but resources such as the net devices are a constraint. Regards, Sunil
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h index 9678d32..cea3b14 100644 --- a/include/net/cfg80211.h +++ b/include/net/cfg80211.h @@ -3935,6 +3935,7 @@ struct mgmt_frame_regs { * This callback may sleep. * @reset_tid_config: Reset TID specific configuration for the peer, for the * given TIDs. This callback may sleep. + * @stop_mlo_link_device: Stop the MLO Link device. */ struct cfg80211_ops { int (*suspend)(struct wiphy *wiphy, struct cfg80211_wowlan *wow); @@ -4260,6 +4261,8 @@ struct cfg80211_ops { struct cfg80211_tid_config *tid_conf); int (*reset_tid_config)(struct wiphy *wiphy, struct net_device *dev, const u8 *peer, u8 tids); + void (*stop_mlo_link_device)(struct wiphy *wiphy, + struct wireless_dev *wdev); }; /* @@ -5248,6 +5251,12 @@ struct cfg80211_cqm_config; * @pmsr_free_wk: (private) peer measurements cleanup work * @unprot_beacon_reported: (private) timestamp of last * unprotected beacon report + * @mlo_list: Used to collect the MLO links. Applicable for iftype + * NL80211_IFTYPE_MLO_LINK_DEVICE. + * @mlo_link_wdev_list: MLO Link wdev's list associated for the current + * MLO connection. Applicable for iftype NL80211_IFTYPE_STATION. + * @mld_wdev: MLD (MLO Data) wdev associated for the MLO link wdev for + * an MLO connection. Applicable for iftype NL80211_IFTYPE_MLO_LINK_DEVICE. */ struct wireless_dev { struct wiphy *wiphy; @@ -5327,6 +5336,9 @@ struct wireless_dev { struct work_struct pmsr_free_wk; unsigned long unprot_beacon_reported; + struct list_head mlo_list; + struct list_head mlo_link_wdev_list; + struct wireless_dev *mld_wdev; }; static inline u8 *wdev_address(struct wireless_dev *wdev) @@ -6828,6 +6840,16 @@ struct cfg80211_fils_resp_params { }; /** + * struct cfg80211_mlo_link_device_params - MLO Link device params. + * @wdev: the wireless device associated with the MLO Link device. + * @bss: Entry of bss to which MLO Link got connected to. + */ +struct cfg80211_mlo_link_device_params { + struct wireless_dev *wdev; + struct cfg80211_bss *bss; +}; + +/** * struct cfg80211_connect_resp_params - Connection response params * @status: Status code, %WLAN_STATUS_SUCCESS for successful connection, use * %WLAN_STATUS_UNSPECIFIED_FAILURE if your device cannot give you @@ -6866,6 +6888,8 @@ struct cfg80211_connect_resp_params { size_t resp_ie_len; struct cfg80211_fils_resp_params fils; enum nl80211_timeout_reason timeout_reason; + const struct cfg80211_mlo_link_device_params *mlo_links; + int n_mlo_links; }; /** diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h index 3e0d4a0..2b01e4f 100644 --- a/include/uapi/linux/nl80211.h +++ b/include/uapi/linux/nl80211.h @@ -2534,6 +2534,11 @@ enum nl80211_commands { * This is a u8 attribute that encapsulates one of the values from * &enum nl80211_sae_pwe_mechanism. * + * @NL80211_ATTR_MLO_LINK_INFO: MLO Links connection information. + * It is a nested attribute, carrying the MLO links connection information. + * Carries the %NL80211_ATTR_WIPHY, %NL80211_ATTR_WDEV, of each MLO Link + * device, along with the connected BSSID for that link through + * %NL80211_ATTR_MAC. * @NUM_NL80211_ATTR: total number of nl80211_attrs available * @NL80211_ATTR_MAX: highest attribute number currently defined * @__NL80211_ATTR_AFTER_LAST: internal use @@ -3025,6 +3030,8 @@ enum nl80211_attrs { NL80211_ATTR_SAE_PWE, + NL80211_ATTR_MLO_LINK_INFO, + /* add attributes here, update the policy in nl80211.c */ __NL80211_ATTR_AFTER_LAST, @@ -3110,6 +3117,7 @@ enum nl80211_attrs { * @NL80211_IF_TYPE_OCB: Outside Context of a BSS * This mode corresponds to the MIB variable dot11OCBActivated=true * @NL80211_IFTYPE_NAN: NAN device interface type (not a netdev) + * @NL80211_IFTYPE_MLO_LINK_DEVICE: MLO Link device interface type (not a netdev). * @NL80211_IFTYPE_MAX: highest interface type number currently defined * @NUM_NL80211_IFTYPES: number of defined interface types * @@ -3131,6 +3139,7 @@ enum nl80211_iftype { NL80211_IFTYPE_P2P_DEVICE, NL80211_IFTYPE_OCB, NL80211_IFTYPE_NAN, + NL80211_IFTYPE_MLO_LINK_DEVICE, /* keep last */ NUM_NL80211_IFTYPES, @@ -5908,6 +5917,8 @@ enum nl80211_feature_flags { * @NL80211_EXT_FEATURE_BEACON_RATE_HE: Driver supports beacon rate * configuration (AP/mesh) with HE rates. * + * @NL80211_EXT_FEATURE_MLO: Driver/device supports MLO (Multi Link Operation). + * * @NUM_NL80211_EXT_FEATURES: number of extended features. * @MAX_NL80211_EXT_FEATURES: highest extended feature index. */ @@ -5969,6 +5980,7 @@ enum nl80211_ext_feature_index { NL80211_EXT_FEATURE_FILS_DISCOVERY, NL80211_EXT_FEATURE_UNSOL_BCAST_PROBE_RESP, NL80211_EXT_FEATURE_BEACON_RATE_HE, + NL80211_EXT_FEATURE_MLO, /* add new features before the definition below */ NUM_NL80211_EXT_FEATURES, diff --git a/net/wireless/chan.c b/net/wireless/chan.c index e4030f1..1a5bb09 100644 --- a/net/wireless/chan.c +++ b/net/wireless/chan.c @@ -532,6 +532,7 @@ int cfg80211_chandef_dfs_required(struct wiphy *wiphy, case NL80211_IFTYPE_AP_VLAN: case NL80211_IFTYPE_P2P_DEVICE: case NL80211_IFTYPE_NAN: + case NL80211_IFTYPE_MLO_LINK_DEVICE: break; case NL80211_IFTYPE_WDS: case NL80211_IFTYPE_UNSPECIFIED: @@ -678,6 +679,7 @@ bool cfg80211_beaconing_iface_active(struct wireless_dev *wdev) case NL80211_IFTYPE_MONITOR: case NL80211_IFTYPE_AP_VLAN: case NL80211_IFTYPE_P2P_DEVICE: + case NL80211_IFTYPE_MLO_LINK_DEVICE: /* Can NAN type be considered as beaconing interface? */ case NL80211_IFTYPE_NAN: break; @@ -1278,6 +1280,7 @@ cfg80211_get_chan_state(struct wireless_dev *wdev, break; case NL80211_IFTYPE_STATION: case NL80211_IFTYPE_P2P_CLIENT: + case NL80211_IFTYPE_MLO_LINK_DEVICE: if (wdev->current_bss) { *chan = wdev->current_bss->pub.channel; *chanmode = CHAN_MODE_SHARED; diff --git a/net/wireless/core.c b/net/wireless/core.c index f6b744e..24aab59 100644 --- a/net/wireless/core.c +++ b/net/wireless/core.c @@ -261,6 +261,31 @@ void cfg80211_stop_nan(struct cfg80211_registered_device *rdev, rdev->opencount--; } +void cfg80211_stop_mlo_link_device(struct cfg80211_registered_device *rdev, + struct wireless_dev *wdev) +{ + ASSERT_RTNL(); + + if (WARN_ON(wdev->iftype != NL80211_IFTYPE_MLO_LINK_DEVICE)) + return; + + if (!wdev_running(wdev)) + return; + + rdev_stop_mlo_link_device(rdev, wdev); + wdev->is_running = false; + + rdev->opencount--; + + if (rdev->scan_req && rdev->scan_req->wdev == wdev) { + if (WARN_ON(!rdev->scan_req->notified && + (!rdev->int_scan_req || + !rdev->int_scan_req->notified))) + rdev->scan_req->info.aborted = true; + ___cfg80211_scan_done(rdev, false); + } +} + void cfg80211_shutdown_all_interfaces(struct wiphy *wiphy) { struct cfg80211_registered_device *rdev = wiphy_to_rdev(wiphy); @@ -281,6 +306,9 @@ void cfg80211_shutdown_all_interfaces(struct wiphy *wiphy) case NL80211_IFTYPE_NAN: cfg80211_stop_nan(rdev, wdev); break; + case NL80211_IFTYPE_MLO_LINK_DEVICE: + cfg80211_stop_mlo_link_device(rdev, wdev); + break; default: break; } @@ -1118,6 +1146,9 @@ static void __cfg80211_unregister_wdev(struct wireless_dev *wdev, bool sync) case NL80211_IFTYPE_NAN: cfg80211_stop_nan(rdev, wdev); break; + case NL80211_IFTYPE_MLO_LINK_DEVICE: + cfg80211_stop_mlo_link_device(rdev, wdev); + break; default: break; } @@ -1200,6 +1231,7 @@ void __cfg80211_leave(struct cfg80211_registered_device *rdev, break; case NL80211_IFTYPE_P2P_DEVICE: case NL80211_IFTYPE_NAN: + case NL80211_IFTYPE_MLO_LINK_DEVICE: /* cannot happen, has no netdev */ break; case NL80211_IFTYPE_AP_VLAN: @@ -1254,6 +1286,8 @@ void cfg80211_init_wdev(struct cfg80211_registered_device *rdev, spin_lock_init(&wdev->mgmt_registrations_lock); INIT_LIST_HEAD(&wdev->pmsr_list); spin_lock_init(&wdev->pmsr_lock); + INIT_LIST_HEAD(&wdev->mlo_link_wdev_list); + INIT_LIST_HEAD(&wdev->mlo_list); INIT_WORK(&wdev->pmsr_free_wk, cfg80211_pmsr_free_wk); /* diff --git a/net/wireless/core.h b/net/wireless/core.h index e1ec9ac..785d7c6 100644 --- a/net/wireless/core.h +++ b/net/wireless/core.h @@ -532,6 +532,9 @@ void cfg80211_leave(struct cfg80211_registered_device *rdev, void cfg80211_stop_p2p_device(struct cfg80211_registered_device *rdev, struct wireless_dev *wdev); +void cfg80211_stop_mlo_link_device(struct cfg80211_registered_device *rdev, + struct wireless_dev *wdev); + void cfg80211_stop_nan(struct cfg80211_registered_device *rdev, struct wireless_dev *wdev); diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c index b76bdc8..189ca2c 100644 --- a/net/wireless/nl80211.c +++ b/net/wireless/nl80211.c @@ -718,6 +718,7 @@ static const struct nla_policy nl80211_policy[NUM_NL80211_ATTR] = { [NL80211_ATTR_SAE_PWE] = NLA_POLICY_RANGE(NLA_U8, NL80211_SAE_PWE_HUNT_AND_PECK, NL80211_SAE_PWE_BOTH), + [NL80211_ATTR_MLO_LINK_INFO] = { .type = NLA_NESTED }, }; /* policy for the key attributes */ @@ -1400,6 +1401,7 @@ static int nl80211_key_allowed(struct wireless_dev *wdev) case NL80211_IFTYPE_ADHOC: case NL80211_IFTYPE_STATION: case NL80211_IFTYPE_P2P_CLIENT: + case NL80211_IFTYPE_MLO_LINK_DEVICE: if (!wdev->current_bss) return -ENOLINK; break; @@ -3805,6 +3807,7 @@ static int nl80211_new_interface(struct sk_buff *skb, struct genl_info *info) return -EOPNOTSUPP; if ((type == NL80211_IFTYPE_P2P_DEVICE || type == NL80211_IFTYPE_NAN || + type == NL80211_IFTYPE_MLO_LINK_DEVICE || rdev->wiphy.features & NL80211_FEATURE_MAC_ON_CREATE) && info->attrs[NL80211_ATTR_MAC]) { nla_memcpy(params.macaddr, info->attrs[NL80211_ATTR_MAC], @@ -3858,11 +3861,13 @@ static int nl80211_new_interface(struct sk_buff *skb, struct genl_info *info) wdev->mesh_id_up_len); wdev_unlock(wdev); break; + case NL80211_IFTYPE_MLO_LINK_DEVICE: case NL80211_IFTYPE_NAN: case NL80211_IFTYPE_P2P_DEVICE: /* - * P2P Device and NAN do not have a netdev, so don't go - * through the netdev notifier and must be added here + * P2P Device, NAN and MLO Link device do not have a netdev, + * so don't go through the netdev notifier and must be added + * here */ cfg80211_init_wdev(rdev, wdev); break; @@ -11125,6 +11130,7 @@ static int nl80211_register_mgmt(struct sk_buff *skb, struct genl_info *info) case NL80211_IFTYPE_MESH_POINT: case NL80211_IFTYPE_P2P_GO: case NL80211_IFTYPE_P2P_DEVICE: + case NL80211_IFTYPE_MLO_LINK_DEVICE: break; case NL80211_IFTYPE_NAN: default: @@ -11181,6 +11187,7 @@ static int nl80211_tx_mgmt(struct sk_buff *skb, struct genl_info *info) case NL80211_IFTYPE_AP_VLAN: case NL80211_IFTYPE_MESH_POINT: case NL80211_IFTYPE_P2P_GO: + case NL80211_IFTYPE_MLO_LINK_DEVICE: break; case NL80211_IFTYPE_NAN: default: @@ -11305,6 +11312,7 @@ static int nl80211_tx_mgmt_cancel_wait(struct sk_buff *skb, struct genl_info *in case NL80211_IFTYPE_AP_VLAN: case NL80211_IFTYPE_P2P_GO: case NL80211_IFTYPE_P2P_DEVICE: + case NL80211_IFTYPE_MLO_LINK_DEVICE: break; case NL80211_IFTYPE_NAN: default: @@ -16023,10 +16031,14 @@ void nl80211_send_connect_result(struct cfg80211_registered_device *rdev, { struct sk_buff *msg; void *hdr; + struct nlattr *nested, *nested_mlo_links; + struct cfg80211_mlo_link_device_params *mlo_link; + int i = 0; msg = nlmsg_new(100 + cr->req_ie_len + cr->resp_ie_len + cr->fils.kek_len + cr->fils.pmk_len + - (cr->fils.pmkid ? WLAN_PMKID_LEN : 0), gfp); + (cr->fils.pmkid ? WLAN_PMKID_LEN : 0) + + (cr->n_mlo_links ? cr->n_mlo_links * 32 : 0), gfp); if (!msg) return; @@ -16065,6 +16077,32 @@ void nl80211_send_connect_result(struct cfg80211_registered_device *rdev, nla_put(msg, NL80211_ATTR_PMKID, WLAN_PMKID_LEN, cr->fils.pmkid))))) goto nla_put_failure; + if (cr->n_mlo_links) { + nested = nla_nest_start(msg, NL80211_ATTR_MLO_LINK_INFO); + if (!nested) + goto nla_put_failure; + + for (i = 0; i < cr->n_mlo_links; i++) { + mlo_link = (struct cfg80211_mlo_link_device_params *)&cr->mlo_links[i]; + nested_mlo_links = nla_nest_start(msg, i + 1); + if (!nested_mlo_links) + goto nla_put_failure; + + if ((mlo_link->wdev && + nla_put_u32(msg, NL80211_ATTR_WIPHY, + wiphy_to_rdev(mlo_link->wdev->wiphy)->wiphy_idx)) || + (mlo_link->wdev && + nla_put_u64_64bit(msg, NL80211_ATTR_WDEV, wdev_id(mlo_link->wdev), + NL80211_ATTR_PAD)) || + (mlo_link->bss && + nla_put(msg, NL80211_ATTR_MAC, ETH_ALEN, mlo_link->bss->bssid))) + goto nla_put_failure; + + nla_nest_end(msg, nested_mlo_links); + } + nla_nest_end(msg, nested); + } + genlmsg_end(msg, hdr); genlmsg_multicast_netns(&nl80211_fam, wiphy_net(&rdev->wiphy), msg, 0, diff --git a/net/wireless/rdev-ops.h b/net/wireless/rdev-ops.h index 5e2f349..68bdfb8 100644 --- a/net/wireless/rdev-ops.h +++ b/net/wireless/rdev-ops.h @@ -1022,6 +1022,14 @@ rdev_nan_change_conf(struct cfg80211_registered_device *rdev, return ret; } +static inline void rdev_stop_mlo_link_device(struct cfg80211_registered_device *rdev, + struct wireless_dev *wdev) +{ + trace_rdev_stop_mlo_link_device(&rdev->wiphy, wdev); + rdev->ops->stop_mlo_link_device(&rdev->wiphy, wdev); + trace_rdev_return_void(&rdev->wiphy); +} + static inline int rdev_set_mac_acl(struct cfg80211_registered_device *rdev, struct net_device *dev, struct cfg80211_acl_data *params) diff --git a/net/wireless/sme.c b/net/wireless/sme.c index 38df713..60a3720 100644 --- a/net/wireless/sme.c +++ b/net/wireless/sme.c @@ -682,6 +682,8 @@ void __cfg80211_connect_result(struct net_device *dev, { struct wireless_dev *wdev = dev->ieee80211_ptr; const u8 *country_ie; + struct cfg80211_mlo_link_device_params *mlo_link; + int i = 0; #ifdef CONFIG_CFG80211_WEXT union iwreq_data wrqu; #endif @@ -783,6 +785,20 @@ void __cfg80211_connect_result(struct net_device *dev, regulatory_hint_country_ie(wdev->wiphy, cr->bss->channel->band, country_ie + 2, country_ie[1]); kfree(country_ie); + + for (i = 0; i < cr->n_mlo_links; i++) { + mlo_link = (struct cfg80211_mlo_link_device_params *)&cr->mlo_links[i]; + if (mlo_link->wdev) { + list_add_rcu(&mlo_link->wdev->mlo_list, &wdev->mlo_link_wdev_list); + mlo_link->wdev->mld_wdev = wdev; + if (mlo_link->bss) { + mlo_link->wdev->current_bss = bss_from_pub(mlo_link->bss); + cfg80211_hold_bss(bss_from_pub(mlo_link->bss)); + } + mlo_link->wdev->is_running = true; + wiphy_to_rdev(mlo_link->wdev->wiphy)->opencount++; + } + } } /* Consumes bss object one way or another */ @@ -833,7 +849,9 @@ void cfg80211_connect_done(struct net_device *dev, ev = kzalloc(sizeof(*ev) + (params->bssid ? ETH_ALEN : 0) + params->req_ie_len + params->resp_ie_len + params->fils.kek_len + params->fils.pmk_len + - (params->fils.pmkid ? WLAN_PMKID_LEN : 0), gfp); + (params->fils.pmkid ? WLAN_PMKID_LEN : 0) + + (params->n_mlo_links ? params->n_mlo_links * + sizeof(struct cfg80211_mlo_link_device_params) : 0), gfp); if (!ev) { cfg80211_put_bss(wdev->wiphy, params->bss); return; @@ -880,6 +898,14 @@ void cfg80211_connect_done(struct net_device *dev, WLAN_PMKID_LEN); next += WLAN_PMKID_LEN; } + if (params->n_mlo_links) { + ev->cr.mlo_links = (struct cfg80211_mlo_link_device_params *)next; + memcpy((void *)ev->cr.mlo_links, params->mlo_links, + params->n_mlo_links * + sizeof(struct cfg80211_mlo_link_device_params)); + next += params->n_mlo_links * + sizeof(struct cfg80211_mlo_link_device_params); + } ev->cr.fils.update_erp_next_seq_num = params->fils.update_erp_next_seq_num; if (params->fils.update_erp_next_seq_num) ev->cr.fils.erp_next_seq_num = params->fils.erp_next_seq_num; @@ -888,6 +914,7 @@ void cfg80211_connect_done(struct net_device *dev, ev->cr.bss = params->bss; ev->cr.status = params->status; ev->cr.timeout_reason = params->timeout_reason; + ev->cr.n_mlo_links = params->n_mlo_links; spin_lock_irqsave(&wdev->event_lock, flags); list_add_tail(&ev->list, &wdev->event_list); @@ -1077,7 +1104,7 @@ EXPORT_SYMBOL(cfg80211_port_authorized); void __cfg80211_disconnected(struct net_device *dev, const u8 *ie, size_t ie_len, u16 reason, bool from_ap) { - struct wireless_dev *wdev = dev->ieee80211_ptr; + struct wireless_dev *wdev = dev->ieee80211_ptr, *mlo_wdev; struct cfg80211_registered_device *rdev = wiphy_to_rdev(wdev->wiphy); int i; #ifdef CONFIG_CFG80211_WEXT @@ -1136,6 +1163,18 @@ void __cfg80211_disconnected(struct net_device *dev, const u8 *ie, wdev->wext.connect.ssid_len = 0; #endif + list_for_each_entry(mlo_wdev, &wdev->mlo_link_wdev_list, mlo_list) { + cfg80211_stop_mlo_link_device(wiphy_to_rdev(mlo_wdev->wiphy), mlo_wdev); + list_del_rcu(&mlo_wdev->mlo_list); + mlo_wdev->mld_wdev = NULL; + if (mlo_wdev->current_bss) { + cfg80211_unhold_bss(mlo_wdev->current_bss); + cfg80211_put_bss(mlo_wdev->wiphy, &wdev->current_bss->pub); + } + mlo_wdev->current_bss = NULL; + mlo_wdev->ssid_len = 0; + } + schedule_work(&cfg80211_disconnect_work); } diff --git a/net/wireless/trace.h b/net/wireless/trace.h index 817c6fe..93f06eb 100644 --- a/net/wireless/trace.h +++ b/net/wireless/trace.h @@ -2139,6 +2139,11 @@ TRACE_EVENT(rdev_set_mac_acl, WIPHY_PR_ARG, NETDEV_PR_ARG, __entry->acl_policy) ); +DEFINE_EVENT(wiphy_wdev_evt, rdev_stop_mlo_link_device, + TP_PROTO(struct wiphy *wiphy, struct wireless_dev *wdev), + TP_ARGS(wiphy, wdev) +); + TRACE_EVENT(rdev_update_ft_ies, TP_PROTO(struct wiphy *wiphy, struct net_device *netdev, struct cfg80211_update_ft_ies_params *ftie), diff --git a/net/wireless/util.c b/net/wireless/util.c index 5af8803..c592bb7 100644 --- a/net/wireless/util.c +++ b/net/wireless/util.c @@ -1017,6 +1017,8 @@ int cfg80211_change_iface(struct cfg80211_registered_device *rdev, WLAN_REASON_DEAUTH_LEAVING, true); wdev_unlock(dev->ieee80211_ptr); break; + case NL80211_IFTYPE_MLO_LINK_DEVICE: + break; case NL80211_IFTYPE_MESH_POINT: /* mesh should be handled? */ break; @@ -1065,6 +1067,8 @@ int cfg80211_change_iface(struct cfg80211_registered_device *rdev, case NL80211_IFTYPE_NAN: WARN_ON(1); break; + case NL80211_IFTYPE_MLO_LINK_DEVICE: + break; } }
Multi-link support is introduced in 802.11be specification. This enables Wi-Fi devices with multiple radios to use these links simultaneously for data transfer. This commit introduces a new interface type to represent an MLO link for an MLO connection. A Wi-Fi station's MLO connection to AP shall have multiple links represented by an MLO link and each link need to carry the respective connection information e.g., Connection State, Connected BSS Info, Connection Frequency/properties, etc. Thus, each MLO link of an MLO connection is represented by a wdev of type NL80211_IFTYPE_MLO_LINK_DEVICE. A MLO link wdev does not have an active netdev associated to it but will be similar to that of NL80211_IFTYPE_STATION wdev with respect to maintaining connection state information and providing the required operations to establish an MLO link. One of these MLO Links (wdev’s) needs to be the MLD interface of the MLO connection and this will be the wdev with NL80211_IFTYPE_STATION which has a netdev interface associated. A MLO station can have multiple links to an MLO AP and thus the MLD-wdev interface has to relate to all such MLO link's-wdev's. MLD wdev and MLO link wdev's can also be on different wiphy's if the host driver's register a single wiphy for each supported band/MAC/PHY. MLO link wdev (NL80211_IFTYPE_MLO_LINK_DEVICE) is created by the userspace prior the MLO connection. struct cfg80211_connect_resp_params is now enhanced to also carry MLO link specific (wdev) information along with the connection result. Accordingly, cfg8011 shall get the information of the associated MLO link's for the MLO connection and will notify the same to the userspace. User space entities will be able to configure the keys ( GTK / IGTK ) or any other MLO link specific information on the respective MLO link wdev. Please note that the enhancements in this commit are aimed to initiate the design review. These changes have not yet been tested. Also, this commit highlights the main areas that would need changes and would need additional enhancements to make it complete. One instance on this aspect is to consider a cfg80211 ops to start the mlo link device (say start_mlo_link_device) for either the STA or AP interface. This interface shall pair with stop_mlo_link_device and thus provide the option for the user space to start/stop a specicic MLO link. This again can be an optional interface which can be used at the discretion of the driver architectures (driver's implicitly starting an MLO link need not rely on this control from user space). Signed-off-by: Sunil Dutt <usdutt@codeaurora.org> --- include/net/cfg80211.h | 24 ++++++++++++++++++++++++ include/uapi/linux/nl80211.h | 12 ++++++++++++ net/wireless/chan.c | 3 +++ net/wireless/core.c | 34 ++++++++++++++++++++++++++++++++++ net/wireless/core.h | 3 +++ net/wireless/nl80211.c | 44 +++++++++++++++++++++++++++++++++++++++++--- net/wireless/rdev-ops.h | 8 ++++++++ net/wireless/sme.c | 43 +++++++++++++++++++++++++++++++++++++++++-- net/wireless/trace.h | 5 +++++ net/wireless/util.c | 4 ++++ 10 files changed, 175 insertions(+), 5 deletions(-)