Received-SPF: softfail (google.com: domain of transitioning linux-wireless-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19;
Message-ID: <467e7f83270a9b1f8e2b32f27b48607e2c2ff480.camel@sipsolutions.net>
Subject: Re: [RFC v2] mac80211: prepare sta handling for MLO support
From:   Johannes Berg <johannes@sipsolutions.net>
To:     Sriram R <quic_srirrama@quicinc.com>,
        linux-wireless@vger.kernel.org
Date:   Mon, 04 Apr 2022 15:22:38 +0200
In-Reply-To: <1648555198-8065-1-git-send-email-quic_srirrama@quicinc.com>
References: <1648555198-8065-1-git-send-email-quic_srirrama@quicinc.com>
Content-Type: text/plain; charset="UTF-8"
User-Agent: Evolution 3.42.4 (3.42.4-1.fc35) 
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Precedence: bulk

On Tue, 2022-03-29 at 17:29 +0530, Sriram R wrote:
> Currently in mac80211 each STA object is represented
> using sta_info datastructure with the associated
> STA specific information and drivers access ieee80211_sta
> part of it.
> 
> With MLO (Multi Link Operation) support being added
> in 802.11be standard, though the association is logically
> with a single Multi Link capable STA, at the physical level
> communication can happen via different advertised
> links (uniquely identified by Channel, operating class,
> BSSID) and hence the need to handle multiple link
> STA parameters within a composite sta_info object
> called the MLD STA. The different link STA part of
> MLD STA are identified using the link address which can
> be same or different as the MLD STA address and unique
> link id based on the link vif.
> 
> To support extension of such a model, the sta_info
> datastructure is modified to hold multiple link STA
> objects with link specific params currently within
> sta_info moved to this new structure. Similarly this is
> done for ieee80211_sta as well which will be accessed
> within mac80211 as well as by drivers, hence trivial
> driver changes are expected to support this.
> 
> For current non MLO supported drivers, only one link STA
> is present and link information is accessed via 'deflink'
> member.
> 
> Note for MLO supported drivers:
> In mac80211 ops, the link id can be fetched from the
> passed link vif struct (TBD) and corresponding link STA
> within ieee80211_sta can be accessed. If the vif passed to
> the driver is a MLD vif in any case, it implies all
> the affliated link vif and its link STA needs to
> be handled for the particular mac80211 op.
> 
> In mac80211 for MLO usage, in cases where we need link sta(ex. to
> get MLD STA from link address in 802.11 header) needs a new
> lookup function to search for link sta address, This is TBD.
> For legacy driver too this will work directly since the
> address in sta_info and link_sta_info are same.
> MLD supported drivers need to pass the link id or link
> address and pubsta for ethernet mode to find the link sta.
> Stats are accumulated per link sta and finally aggregated
> if mld sta stats is required. These will be supported along
> with MLO support patches.
> 
> Currently in mac80211, all link STA info are accessed directly
> via deflink. These will be updated to access via link pointers
> indexed by link id with MLO support patches, with link id
> being 0 for non MLO supported cases.
> 

I think this looks fine - want to send it as a PATCH? I think I'll just
apply the spatch directly.

If there's any needed fixups beyond the spatch that might be good to
know too.

johannes