On Wed, 2014-01-22 at 11:19 +0100, Johannes Berg wrote: > On Wed, 2014-01-22 at 11:13 +0100, Michal Kazior wrote: > > > > That seems pretty much fine, though I was talking to Luca yesterday and > > > there is actually a case where a CSA chanctx should be usable later, for > > > example if you have this: > > > * managed mode interface receives a channel switch announcements and > > > acts on it > > > * it also sends an event to userspace (this is a TODO but we're on it) > > > * wpa_s decides that a concurrent GO should also switch > > > > Hmm. This sounds interesting. But it makes me wonder.. > > > > If STA iface receives CSA it starts it right away? It doesn't care if > > other interfaces are using a given channel context too? It just > > assumes other intefaces may actively request channel switch and if > > they do, the CSA will be 'aggregated/merged'? > > Well, in Luca's implementation a new channel context has to be > available. In the current implementation, it will simply disconnect if > using chanctx, or if there's any other interface using the channel (I > believe) Yes, that's right. Unless the channel context we're going to switch to already exists. Let's say: we have a STA in channel 1 and a GO in channel 11; the STA receives a CSA from its AP to change to channel 11; the STA interface "reserves" the channel 11 context. The context already exists, so we don't need a new one and, since we reserve it, it will remain available, even if the GO goes away from it. I don't think we should try to merge the channel switches. We should just perform them separately, especially because the exact time of the switch will most likely not be the same (since the TBTTs are not in sync). In the STA and GO sharing the context case, the idea is that the STA interface will send a notification to userspace and let the userspace take action. In this case, the userspace will trigger a GO CSA as well. The userspace will decide the exact timing of the GO CSA (it should be as close as possible to the original STA CSA). The userspace will probably tell the GO to switch to the same context as the STA is switching to, so both will end up reserving the same channel context. The non-chanctx case needs to be considered separately. As Johannes already mentioned, I simply ignored non-chanctx in my patch for now. :P > > What about cfg80211 intf combinations? If GO sends a channel switch it > > will fail on num_available_channels unless you implicitly consider the > > userspace event you mentioned or export CSA state down to cfg80211. > > Yeah, that's a good point, need to consider that. Very good point. I hadn't thought about it. When mac80211 decides to change channel to an existing context, it needs to know whether the combination will be valid or not. > > At one point I was wondering if channel contexts should be actually > > exposed in cfg80211. It would probably make it easier to coordinate > > some CSA scenarios like this in a sane way, don't you think? But then > > again that's quite big of a change. > > Yeah that'd be a bit of a change, but maybe it's worth it? Not sure. That's probably going to be necessary. How would mac80211 be able to know if the future combination would be possible or not? I thought about asking cfg80211 if the combination would be okay when reserving a context, but that wouldn't work if we have >= 2 reservations. cfg80211 needs to know about the reservations as well. :( -- Luca. -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
