On 10/12/2023 4:53 AM, Johannes Berg wrote:
Hi Aloka, all,
Reviving an ancient thread, but this is where we discussed these things
last I think ...
So I said, back at the beginning of 2022:
Conceptually, I'm wondering if it really belongs into the chandef? Can
you explain why it's part of the channel configuration? If you've got
two chandefs with the same control channel, CCFS and bandwidth, but
different puncturing, does it really make sense to treat them as two
separate channel contexts, e.g. in mac80211? It seems strange to do
that.
And you replied two things:
Added it here so that any command working with chandef will be updated
without any other change.
Example: During channel switch, user can provide a puncturing bitmap
with a new option I added in userspace, and because it is part of
chandef, the same code path validates it for that command automatically.
Yeah but is it really a CSA/chanswitch if the puncturing changes? I
don't think so?
Which, well, I think I was confused about - it could we CSA/chanswitch
depending on what you actually want to do, i.e. it's up to the AP to do
this as just a puncturing bitmap update in the beacon, or with CSA. It
might do one way or the other depending on what it wants...
But also, I read this as being a bit more about the software POV, which
I didn't really think was the most important part.
>
And also, you said:
Regarding if different puncturing pattern should be considered as a new
context - yes, depending on if it is HE or non-HE mode, the new bitmap
may be invalid and the operation should fail.
Which I'm not sure I understood then, and certainly not sure I
understand now, but I said:
802.11be allows only few patterns when AP is operating in non-OFDMA mode
but if OFDMA is used then each 80 MHz sub-block can have a different
puncturing pattern when BW > 80MHz.
I know *_HE was not the best terminology, originally it was *_OFDMA but
later changed because we decided to base the puncturing bitmap
validation based on HE vs older modes.
Function "cfg80211_ru_punct_bitmap_valid" added in this version first
checks for non-OFDMA patterns, and only if "ru_punct_bitmap_supp_he"
attribute is set by the userspace then it goes further to also check
against patterns allowed for OFDMA.
I could not find any other way to decide OFDMA vs non-OFDMA than letting
userspace explicitly indicate latter.
It would be great if you can provide your inputs on this.
That wasn't really the question though. Consider this:
Say you have STA + STA, if the first STA is connected to an AP with no
puncturing, and the second STA is connected to an AP where the channel
and bandwidth are the same, but some puncturing is done, should that
really be two channel contexts as far as mac80211 is concerned, and thus
require channels=2 in the interface combinations etc.? It doesn't seem
right to me.
Or consider AP + STA, where the AP is set up for some channel but the
STA is connecting to an AP on the exact same channel, but with
puncturing... Again, same thing, I don't think it should consume two
channel resources.
Which, actually, I've learned since that I was completely wrong about!
It should, and likely must, in fact be two separate channel contexts,
with all the limitations that implies.
The thing is - back then I was making not just one, but in fact *two*
wrong assumptions:
1. The DSP/radio can receive punctured PPDUs if listening on the non
punctured channel.
At least for our device that's not true, not sure about ath12k? It
seems you have a per-peer puncturing configuration even, but that
seems odd, and it's always just set to the vif puncturing
configuration.
Yes, same vif puncturing pattern is assigned for all the peers
associated on that vif, but firmware requires it to be sent separately
for each peer.
2. You can simply transmit punctured PPDUs when on a non-punctured
channel, i.e. it's just a rate control decision.
This is perhaps less important, but it's also not really true.
While you can clearly _transmit_ this way, that's not the only
thing - you also need to do the CCA before transmitting, and if
there's noise/interference on the punctured channel, you'd much
more rarely find the channel to be clear and be able to transmit
if this doesn't consider the puncturing, but that's something to
do sort of generally in the background for the transmit.
It might be possible to work around #2, but I'm not sure it's possible
to work around #1?
So I think I have two questions:
A. Would you object if I moved the puncturing into the chandef after
all?
This is where I'm getting confused.
The main reason to put in chandef was that I thought of the bitmap as a
radio characteristic (not vif). But after you brought up that AP+STA
mode can have different bitmaps, even though all other channel
characteristics (width, cf etc) are same, I realized my original
assumption wrong incorrect.
Moving the bitmap to cfg80211_ap_settings() meant that each AP vif can
have different bitmap, and I'm guessing you similarly added for each STA
vif context.
Now if you move it back into chandef, how exactly will this work if you
need different bitmaps?
B. How does ath12k cope #1/#2 above? Would we need to have a callback
to the driver to compare if two channel contexts are compatible or
not (e.g. if they have different puncturing), or does ath12k also
have limitations on RX/TX that mean it would actually prefer two
channel contexts for the cases I had outlined in the quoted text
above (STA+STA/AP+STA)?
If we do end up moving the bitmap back to chandef, we may need some
changes, because as I said above, when I originally added it I hadn't
thought of different bitmaps for each vif.
But can you give an example of what you would consider as compatible
channel contexts and what would be incompatible? I'm not clear on that part.
Thanks,
Aloka.
