Received-SPF: pass (google.com: domain of linux-wireless+bounces-3506-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Message-ID: <ac5825e8-0cb1-476e-be5c-ad0170122f77@quicinc.com>
Date: Tue, 13 Feb 2024 10:46:31 +0530
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v8 4/5] wifi: mac80211: start and finalize channel switch
 on link basis
To: Johannes Berg <johannes@sipsolutions.net>
CC: <linux-wireless@vger.kernel.org>,
        Jeff Johnson
	<quic_jjohnson@quicinc.com>,
        Ilan Peer <ilan.peer@intel.com>, Jouni Malinen
	<j@w1.fi>,
        Ping-Ke Shih <pkshih@realtek.com>, Ryder Lee
	<ryder.lee@mediatek.com>
References: <20240130140918.1172387-1-quic_adisi@quicinc.com>
 <20240130140918.1172387-5-quic_adisi@quicinc.com>
 <b73dd1f9c23c164179c38e2109aa1550d87e87ed.camel@sipsolutions.net>
 <646d1e3e404a437f4c99c80996eb4f194ac242b8.camel@sipsolutions.net>
 <26df9aa6-e497-4040-ad5c-c647454acca6@quicinc.com>
 <b2cf5c1d-7842-4e59-b25a-904a6879fa9c@quicinc.com>
 <f7174207668cac149246cafa0e4b4749ee3289f0.camel@sipsolutions.net>
Content-Language: en-US
From: Aditya Kumar Singh <quic_adisi@quicinc.com>
In-Reply-To: <f7174207668cac149246cafa0e4b4749ee3289f0.camel@sipsolutions.net>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit

On 2/12/24 20:16, Johannes Berg wrote:
> So ... I'm looking at the client side, and thinking about that.
> According to the spec, multi-link element should be present in beacons
> of APs affiliated with the same MLD if one of the (other) links is doing
> CSA, and then have also the CSA counters of course, relative to the
> target link's TBTT (of course.)
> 

Yes correct, you are referring to critical update(s) right?

> Theoretically, both mac80211 and hostapd today support different beacon
> interval on different links, I believe.
> 
> This makes the whole thing of including CSA for link A on beacons/probe
> responses transmitted on link B very tricky, because you have to know
> the timing, etc.

At least handling for probe response seems to be a bit easier since 
there we need not maintain any timer as such (as you have said too - we 
need not be perfect there). But beacons, as you said, it is indeed bit 
tricky to handle full support considering both links could beacon at 
different intervals.

> 
> For the CSA counter of a link _itself_ we have counter_offsets_beacon
> and counter_offsets_presp (for probe response offload) in struct
> cfg80211_csa_settings, and also counter offsets in struct
> cfg80211_mgmt_tx_params for sending probe responses.
> 
> But ... for the cross-link information in the MLE this gets way more
> tricky? Especially if the beacon interval is different - we couldn't
> just count down, we'd have to fill in the information when we know where
> the frame is transmitted. For probe responses maybe we can afford to not
> be perfect, but for beacons it better be right - so we have to calculate
> the right counter value(s) for (all of) the switching link(s) according
> to the current TSF, TSF offset and TBTT - not all of which we even have
> in the driver?
> 

Yes correct :)

> I can see a few ways of implementing this:
> 
>   a) Punt to firmware and it parses the multi-link element etc. to
>      find the places to update. But that's awful, it requires parsing
>      possibly fragmented MLE with fragmented subelements containing the
>      CSA elements inside ...
> 
>   b) Punt to firmware and give it a (possibly long) list of offsets K_N
>      where to put the N'th counter for link K when transmitting the
>      frame.
> 

At least for beacons if firmware takes care of it then it will be good. 
Firmware could maintain the counter (for the affected link) and (I 
assume it will be aware of the partner links) so whenever partner link 
transmits a beacon it could add the CSA (or such IEs) in per STA profile 
of the reporting link. It could get the contents from the affected link 
but actual value of the counter could be filled from the global counter 
being maintained. But not sure whether we can force every driver's 
firmware to do so?

Let aside actual drivers, adding the test case for mac80211_hw_sim would 
also be tricky since there beacon Tx is handled in software only.


>   c) Require the get_tsf operation and add an operation to retrieve TSF
>      offset (**), and then calculate the TBTT for each link when
>      beacon_get is called with the per-link beacon intervals and update
>      the values correctly if CSA is in progress on any link ... requires
>      against parsing like in (a) or offset information like in (b), but
>      at least now it's in software?
>      For probe responses this could be a bit off I guess, but maybe that
>      doesn't matter as much - probe responses are not authenticated so a
>      client probably shouldn't use them for real CSA anyway.
> 
>      (**) which I guess we need anyway for hostapd to put it into beacons
>      etc.?

Yes I'm too anticipating hostapd changes to support the critical update.

> 
>   d) Require beacon intervals to be the same, and then just count down?
>      Still requires the offset information etc., but that's also not
>      great because if the configuration happens during a TBTT on any of
>      the links (some before, some after), it'll be very wrong. So not
>      very inclined to do this one ...
> 

Agreed. Can't enforce the intervals to be same.

> 
> Do you have any plans for any of this?

I do have some idea (possibly half baked code) for handling critical 
updates in probe responses. Beacons, I assume firmware takes care hence 
I have changes to mark it in the link_conf so that drivers could read 
that and give it to its firmware.
Handling in beacon at kernel level, I need to think of it since anyways 
hw_sim test case is good to have :)

Do we have any data right now, how many actual drivers have offloaded 
beacon Tx to its firmware (at least those who are supporting Wi-Fi 7)?
If we could see majority are using firmware then we could first add 
support for such drivers then we can think about handling it in kernel?

> 
> I'm mostly asking right now because I want a reliable way to test the
> work I'm trying to do on the client side though, so I could also live
> with some hacks (inject through debugfs?), but having it for real would
> be nice.

Okay. I'm right now working to add basic test case in hw_sim for MLO CSA 
(on first link) as we discussed. There is need of a few mac80211 changes 
in order to support for other links. I'm checking those now. Once done 
with these, then I'll take up critical updates.