[PATCH wireless-next 0/3] wifi: Preamble puncturing support for mesh

[Johannes Berg]

Hi,

Sorry for the late reply - going through and saw I missed this.

On Mon, 2025-07-14 at 00:29 +0530, Ramasamy Kaliappan wrote:
> 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.

Well I guess a device still has two settings:

 - per STA what it can actually transmit to that STA
 - for yourself, what BW you will receive and do CCA for

Given the CCA, obviously the per-STA channels used must be a subset of
the ones used by the device.

Which interesting because if say one STA has 80 MHz channel 36 (and
secondaries 40/44/48) with puncturing bitmap 0x8 (i.e. using 36/40/44)
and the other STA has the same with puncturing bitmap 0x4 (i.e. using
36/40/48) then effectively they can only communicate on 40 MHz,
_however_ they're both doing CCA on their respective 60 MHz. That's ...
inefficient?

But I guess it's also unavoidable unless you only have a single STA or
so. Or want to reduce the bandwidth when ... ohh, we have this "min_def"
concept in mac80211, we could use that here for mesh as well? We already
do almost precisely this for AP mode. And for client side I used it for
OMI stuff. So I guess here we could - whenever STAs are added/removed -
recalculate the min_def, and thereby in this case avoid doing CCA on the
whole 80/60 MHz channel. Actually seems fairly easy.

But also then that can be future optimisation. Arguably, it could
already be done today without puncturing, when other mesh STAs are just
not even using 80 MHz for example.

> Yes that's right, the intersection and BW selection is done for every 
> PPDU at Firmware.

Seems like one of those "we want to do more firmware" cases ;-) Intel is
certainly not immune to that either :)

> When not considering CSA scenario then the puncturing pattern is an 
> intersection of the local channel def and puncturing pattern advertised 
> by peer.

Right.

> 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.

Makes sense.

> However, unless the new bitmap is explicitly forwarded to userspace, the 
> userspace component might not be aware of the bitmap changes.

Does it have to? But the bitmap is part of the chandef so userspace
should be aware of it.

> 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

Honestly I'm not completely sure how CSA works in mesh today, so I guess
I'll just leave it to you to consider.

> > Did you think about any of these questions, or are you just using me as
> > a design tool? ;-)
> > 
> 
> No, certainly not Johannes! 😊

:-)

johannes