On 6/30/2025 6:51 PM, Johannes Berg wrote:
On Fri, 2025-06-27 at 19:49 +0530, Ramasamy Kaliappan wrote:
I ... don't really understand how this is supposed to work.
Say, for the sake of simplicity, we have an 80 MHz channel, the lowest
channel is the control channel (so puncturing 0x1 is invalid). Possible
puncturing values are 0x2, 0x4 and 0x8.
If locally we have 0x2, that means (I assume, since that's how chandef
is meant to work) CCA and RX is always on the control channel and upper
40 MHz parts. If you're now going to transmit to a station that has
puncturing 0x8, you didn't do CCA on the 0x2 subchannel, but ...
transmit anyway?
Yes,we do not transmit blindly to mesh peers with different puncturing.
Before initiating transmission, the driver computes the intersection of
the local and peer puncturing bitmaps to determine the set of valid sub
channels.
Hm, I guess that's fair, but why not do that in mac80211 instead, that'd
be simpler and far more obvious/safe?
Hmm, I originally thought the bandwidth determination would need to
happen within the driver, since it’s required at the time of packet
transmission for each mesh STA. The assumption was partly influenced by
our existing firmware design.
But yeah, since the bandwidth doesn’t really change much across PPDUs
for the same STA, it actually makes more sense to handle it in mac80211
and drivers can use it.
Also, clearly your driver _doesn't_ do what you say "the driver" does,
if anything it magically and "undocumentedly" happens in firmware.
Yes that's right, the intersection and BW selection is done for every
PPDU at Firmware.
I mean, maybe this could work if the remote puncturing is a superset of
the local puncturing? But just blindly doing it the way it appears to be
done in this patchset seems ... questionable at best?
Can you explain more how this is even supposed to work?
When associating with a mesh peer, the mesh peer's puncture pattern is
shared with the driver. The driver evaluates the intersection of this
bitmap with local pattern.
Could also be done in mac80211, I guess.
Thats right
if the resulting pattern corresponds to valid transmission bandwidth,
the valid subchannels used for transmission.
If the resulting pattern does not support a valid bandwidth, the driver
falls back to using only the primary 20 MHz control channel for
transmission.
Right.
I also note that there's not even any definition where the puncturing
pattern is rooted ... is it relative to the local chandef? Relative to
the peer's chandef? Clearly not even that is documented.
When not considering CSA scenario then the puncturing pattern is an
intersection of the local channel def and puncturing pattern advertised
by peer.
If the local and peer mesh are capable of EHT, the negotiated EHT
bandwidth of the peer mesh is considered first. The intersection of
puncturing patterns is then applied on top of this to derive
bandwidth—potentially reduced and with or without additional puncturing.
What happens if
the bitmap changes? Why does userspace track it rather than mac80211,
When a channel switch is triggered by a userspace application,
the user space is fully aware of the bitmap changes and pass them to the
mac80211 driver.
But when a peer mesh initiates a channel switch via CSA, the mac80211
driver on the local mesh receives bitmap changes through CSA
beacon/action frames and processes the channel changes internally.
However, unless the new bitmap is explicitly forwarded to userspace, the
userspace component might not be aware of the bitmap changes.
which has the beacon of the peer and handles CSA, so what happens with
puncturing in CSA?
I am thinking something like below for CSA with puncturing in Mesh,
1. Acquire the puncturing bitmap from the peer initiating the CSA action
/ beacon frame.
2. Validate the new channel's compatibility with the new puncturing
pattern, and apply the new channel context.
3. Forward the csa beacon/CSA action.
4. Reset the existing bitmap and apply the new bitmap to associated STAs.
I didn't take care of this in the patch series. I am planning to address
this in the upcoming series
Did you think about any of these questions, or are you just using me as
a design tool? ;-)
No, certainly not Johannes! 😊
I initially assumed the bandwidth would need to be decided by the driver
since it’s tied to packet transmission for each mesh STA— that’s kind of
how the firmware seemed to be built.
johannes
