Re: [PATCH wireless-next v2 1/3] wifi: cfg80211: Add support for S1G Response Indication Configuration

[Johannes Berg <johannes@sipsolutions.net>]

Hi Ria,

> Just wanted to follow up on the earlier reply and check if you've
> had a chance to review it.

Sorry, I had seen it, but it took a backseat to shuffling patches and
other things I had to do, on top of having been somewhat sick until
early this week.

> To explain the implementation a bit more clearly: The issue is that
> response indication from a MAC perspective doesn't really make sense
> elsewhere. It's simply embedded into the PPDU for the VIF that has
> response indication configured, and the receiver uses it to determine
> which type (if any) of ACK to respond with. So it's entirely handled
> by the lower MAC besides of course setting the value from the upper MAC.

Let me summarise that how I understand what you said, and the spec:

The transmitter MAC sets the RESPONSE_INDICATION in the TXVECTOR for the
PHY-TXSTART.request primitive. The (S1G) PHY then embeds this in the
preamble, so that the receiver can react accordingly. There are certain
rules for both transmitter and receiver, but the transmitter MAC has a
certain set of choices for how to set this.

And for the certification test, presumably the choice for testbed STA
(for certain frames at least, I guess not intended to break the rules
for cases where there's no/less choice) is not meant to be left to the
implementation, but rather meant to be set, presumably to check that the
receiver reacts correctly.

(If I got this wrong so far, probably better to stop reading here and
tell me.)


> While it may seem more ideal to sit in a per station or something similar
> where the lifetimes are more natural, there isn't a capability exchange
> that occurs - configuration is more for local transmitter config. On the
> receiver side, it isn't communicated to the upper MAC at all - so considering
> it as a STA entry dosen't really make much sense.

Yes, I can understand that argument in some way. OTOH, while I'd tend to
agree that it somewhat argues against it being a per-STA configuration,
I'm not really sure it really argues _for_ it being an interface config.

Based on the understanding I outlined above, I'd argue the spec doesn't
really say anything to this effect at all. It leaves a choice to the MAC
implementation on how to set it for every individual PPDU it sends.

Now, clearly we can't very well have an implementation where something
in userspace decides for every PPDU, so we have to make an
implementation choice of how the MAC decides. You've made a choice here
that it should be decided per interface, and due to lifetime issue I've
outlined a choice where it decides per (destination) STA. I don't think
from a spec perspective this choice really matters at all, since the
setting of the TXVECTOR is independent for each PHY-TXSTART.request.

Now that I've described it this way, I think the biggest question I have
is actually how, if at all, we need this in a non-testing scenario?
Which choices of implementation makes sense there? What are the use
cases for this other than testing? I think this could inform the
implementation choice here.

(And as an aside, if it ends up being only for testing, then I think we
can also simply stick it in mac80211 debugfs rather than building out
the elaborate cfg80211/nl80211 infrastructure. But we still need to
decide where it should live, although in that case I'd be more willing
to accept an interface setting despite the lifetime issues.)

johannes