Message ID | 20240328055235.3034174-1-quic_mdharane@quicinc.com (mailing list archive) |
---|---|
Headers | show |
Series | Add Multi-Link Reconfigure link removal support | expand |
On Thu, 2024-03-28 at 11:22 +0530, Manish Dharanenthiran wrote: > This is a preparation for supporting Multi-Link reconfigure link removal > procedure[IEEE P802.11be/D5.0 - 35.3.6.3 Removing affiliated APs] for > driver which supports offloaded Multi-Link reconfigure link removal. > > Multi-Link reconfigure link removal offloaded drivers will take care > of updating the reconfiguration MLE in self and partner beacons. I think we need to flesh that out. I don't know if you saw the CSA discussion, but I think it's pretty obvious that the same discussion about partner links is going to apply here. That doesn't necessarily mean that you _have_ to do that in this set (though I'd actually like to see it to support hwsim, for testing purposes of both sides), but I think the way it's written now the API doesn't consider how we might update partner links if it's not automatically handled by firmware, etc. johannes
On 3/28/2024 11:55 PM, Johannes Berg wrote: > On Thu, 2024-03-28 at 11:22 +0530, Manish Dharanenthiran wrote: >> This is a preparation for supporting Multi-Link reconfigure link removal >> procedure[IEEE P802.11be/D5.0 - 35.3.6.3 Removing affiliated APs] for >> driver which supports offloaded Multi-Link reconfigure link removal. >> >> Multi-Link reconfigure link removal offloaded drivers will take care >> of updating the reconfiguration MLE in self and partner beacons. > > I think we need to flesh that out. I don't know if you saw the CSA > discussion, but I think it's pretty obvious that the same discussion > about partner links is going to apply here. That doesn't necessarily > mean that you _have_ to do that in this set (though I'd actually like to > see it to support hwsim, for testing purposes of both sides), but I > think the way it's written now the API doesn't consider how we might > update partner links if it's not automatically handled by firmware, etc. > > johannes Yeah, the intention for this RFC to get some insights from upstream community about the usage of new NL commands and attributes for driver which has the synchronization between partner links in the lower level. Will try to send hwsim changes in a separate one where it handles for both (offload/non-offload) cases. I believe you are referring to discussion here: https://lore.kernel.org/linux-wireless/f7174207668cac149246cafa0e4b4749ee3289f0.camel@sipsolutions.net/ I thought of sending these API(s) with only offloaded driver in design for this RFC which i will try de-couple or make it more generic while sending the upcoming versions. Also, for non-offloaded there are certain API like reporting TSF might be redundant, since, we will do the offset and time calculation either in hostapd or kernel directly. We are still finding ways on how to do that for non-offloaded driver since this might need a similar or additional handling as CSA.