Hi, On Wed, 2024-02-21 at 18:22 +0530, Aditya Kumar Singh wrote: > On 2/21/24 13:39, Johannes Berg wrote: > > Qualcomm: > > - copies and updates CSA/ECSA elements all by itself > > - btw, not sure here about probe responses, does it do that too? > > We had a thought about keeping this CSA/ECSA handling at host/kernel > level only. But the major point of concern is _synchronization_ among > firmware of each of the links participating in the MLD. Sure. > * Even if we ignore TSF/TBTT synchronization for a moment, how firmware > will know when to transmit the beacon with a particular counter or when > CSA has finished on other link? If rely on host's update then there is > room for further delay and hence errors. > - This is because, counter value on the reported link depends on > the last beacon transmitted by the affected link. Sure. I don't think anyone suggested that the host will put the exact counter value there, just to have the template. > * Host can send the template on all links Right. > but how to ensure that first > template is reached on the affected link and then only on the partner > links? Host will queue the command properly but reaping of the command > on n (no of links) independent firmware can not be guaranteed in the > same order in which host has filled. It depends how busy each of host to > firmware path is. True, and there's a potential for race conditions there I suppose, but I suppose in the Intel, Realtek and hwsim case at least we wouldn't have *different* firmwares running multiple links, but a single one. In any case, you could solve this even with multiple, by applying the new template only after you have the CSA'ing link's new beacon template, if it requires filling in CSA counters, or such. > * And then obviously, considering TSF/TBTT will be again complicating > the synchronization part and making it more difficult to manage just via > host. Again, not suggesting that it is managed completely by the host, just the templates. > Hence there is a strong urge to let firmware handle all this for beacons. Sure, that's fine, your call :) > As far as how firmware will _magically_ communicate among themselves is > concerned, we have *IPC* in place to achieve that. One link firmware can > talk to other link firmware when required. :-) It probably doesn't actually help you make it race-free though, so does it really matter? But again, it's your call how you want to do it, and we'll just have to handle it in software appropriately. While I'd prefer to have _one_ way of doing things, at least so far we've basically seen one way of having the host involved and ath12k not having the host involved, so it's all still really simple. > Kernel Level > ____________________________________________________________________________ > -------------- -------------- -------------- > > Firmware 1 | <- IPC -> | Firmware 2 | <- IPC -> | Firmware 3 | > > on HW 1 | | on HW 2 | | on HW 3 | > -------------- -------------- -------------- > > > Hence, host just needs to update template of the affected link and > indicate to firmware that it is a critical update. This firmware then > can indicate other link firmware(s) to append CSA/ECSA IE with a given > counter value to its beacon via this IPC. Sure. You still have a race, because if you send a message over IPC saying that the CSA needs to be included and it's just before the TBTT, chances are the TBTT event will still happen without that. So in a sense it's similar to the host updating the partner link's beacon template "too late". You can have a situation where the CSA link's template is updated just before _its_ TBTT, and the partner link's TBTT is just a little bit later, but the update is delayed ... You could probably solve that by making your IPC synchronous but then you risk your TBTT timings in cases like this. Arguably, I'm not sure it matters. I'm thinking we'll enforce that the CSA must be in progress when updating the partner links beacon/probe response templates referring to it (*), but ... ultimately, I think we can accept that the partner link updates the CSA one beacon later if their TBTTs are very close. (*) and now that I think about it, that might have to immediately come with a separate template to use _after_ the switch, like CSA does for the CSA link > Parsing the IE and > de-fragmenting and fragmenting it again can be done by firmware itself. > (Agree that it is bit complex but when comparing with complexity of > maintaining synchronicity across links, this looks more doable) That sync maintenance is because of your hardware design though, others don't necessarily have that because multiple links are handled by the same NIC, not separate ones. > Hence we have taken "offloading beacons fully to firmware" approach. Sure, fair enough. > For probe responses, it is handled in host/kernel only. Firmware sends > back the last transmitted count in beacon to host. So we have the last > transmitted count info. Per STA profile generation logic is also there. > So we manage via that. So I think like in Realtek's case I'd probably advocate doing that in the driver with the offsets given by hostapd/software stack, although that requires having *two* feature flags, one for beacons and one for probe responses ... since you lack the "magic" for probe responses. johannes
