On 2/21/24 18:38, Johannes Berg wrote:
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.
oh okay, makes sense.
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.
Yes!
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
True. So each link will have to send two templates. beacon_csa and
beacon_after
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.
:) I guess yeah. So this approach we discussed is fine right?
Have some _feature flag_ to indicate whether host would like templates
(with offsets) for reporting links or not. If it does then hostapd can
send those, otherwise it won't. Hosts can further handle as per their need.
