From: Jeff Johnson <quic_jjohnson@quicinc.com>
To: Johannes Berg <johannes@sipsolutions.net>,
Veerendranath Jakkam <quic_vjakkam@quicinc.com>
Cc: <linux-wireless@vger.kernel.org>, <quic_usdutt@quicinc.com>,
Aaron Komisar <akomisar@maxlinear.com>
Subject: Re: [PATCH v2 1/3] cfg80211: Add NL80211_IFTYPE_MLO_LINK type for MLO links on MLD STA
Date: Thu, 17 Mar 2022 14:42:55 -0700 [thread overview]
Message-ID: <aaf86305-3b6e-aa8d-fa9f-b4b4ba9cb3c1@quicinc.com> (raw)
In-Reply-To: <af96eba158c83a63cb9465b04373e909971d7676.camel@sipsolutions.net>
On 3/11/2022 4:17 AM, Johannes Berg wrote:
> On Wed, 2022-02-23 at 16:16 +0530, Veerendranath Jakkam wrote:
>>
>> Two link non-AP MLD representation:
>>
>> wlan0 (non-AP MLD)
>> IFTYPE_STATION (netdev + wdev)
>> / \
>> / \
>> link0 link1
>> IFTYPE_MLO_LINK (wdev) IFTYPE_MLO_LINK (wdev)
>> | |
>> | |
>> radio(2G) radio(5G)
>>
>> In contrast, NL80211_IFTYPE_MLO_LINK can't be used to represent AP MLO
>> link since an MLD AP must support pre-11be and 11be clients
>> simultaneously so each AP MLO link affiliated with AP MLD must also act
>> as independent AP for pre-11be clients so each AP MLO link must be
>> represented by NL80211_IFTYPE_AP associated with a separate netdev.
>>
>> Two link AP MLD representation:
>>
>> AP MLD
>> (netdev + wdev)
>> / \
>> / \
>> wlan0 wlan1
>> IFTYPE_AP IFTYPE_AP
>> (netdev + wdev) (netdev + wdev)
>> | |
>> | |
>> radio(2G) radio(5G)
>
> So just for posterity's sake - we had more discussions on this out of
> band, and decided that the "netdev + wdev" on the wlan0/wlan1 will not
> actually happen - they both should be just "wdev" like in the non-AP
> MLD.
>
> This solves the issue of broadcast (otherwise you'd need AP MLD + wlan0
> + wlan1 in a bridge and drop all multicast at wlan0 and wlan1), at the
> expense of a small amount of flexibility - you cannot consider legacy
> and MLD clients to be in different networks.
>
> However, given the complexities around multicast, you probably cannot
> consider them to be in different networks _anyway_ because then you'd
> have to _not_ drop all the multicast on wlan0/wlan1, and then you send
> multicast twice to the MLD clients, which would be wrong too...
>
> So the more reasonable thing to do is to treat this the same way as non-
> AP MLD with only a single netdev, and effectively behave as if there was
> an internal kind of bridge inside the AP MLD for the legacy clients.
>
> As a consequence, of course this patch will change too.
Although this patch series is specific to non-AP MLD support I advocated
during internal review to add this AP MLD description to initiate
discussion about the differences between the two, and I'm glad to see
that is happening.
Should we just omit the AP MLD representation in v2, and add that with
the AP MLD support?
Did you have any other comments on the series other than your proposal
to add a MLD wiphy flag, and as a result, not require driver to NULL
check the wdev->netdev?
Thanks!
/jeff
next prev parent reply other threads:[~2022-03-17 21:43 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-23 10:46 [PATCH v2 0/3] cfg80211: Add MLO Link Device abstraction Veerendranath Jakkam
2022-02-23 10:46 ` [PATCH v2 1/3] cfg80211: Add NL80211_IFTYPE_MLO_LINK type for MLO links on MLD STA Veerendranath Jakkam
2022-02-23 12:39 ` Arend van Spriel
2022-02-24 3:28 ` Vasanthakumar Thiagarajan
2022-02-24 7:59 ` Veerendranath Jakkam
2022-02-26 19:36 ` Arend Van Spriel
2022-03-11 12:17 ` Johannes Berg
2022-03-17 21:42 ` Jeff Johnson [this message]
2022-02-23 10:46 ` [PATCH v2 2/3] cfg80211: Indicate MLO links info in connect/roam events Veerendranath Jakkam
2022-02-23 10:46 ` [PATCH v2 3/3] cfg80211: Add support for key operations on NL80211_IFTYPE_MLO_LINK Veerendranath Jakkam
2022-03-11 12:20 ` Johannes Berg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aaf86305-3b6e-aa8d-fa9f-b4b4ba9cb3c1@quicinc.com \
--to=quic_jjohnson@quicinc.com \
--cc=akomisar@maxlinear.com \
--cc=johannes@sipsolutions.net \
--cc=linux-wireless@vger.kernel.org \
--cc=quic_usdutt@quicinc.com \
--cc=quic_vjakkam@quicinc.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.