I agree with Luca that we need to leave an option to switch multiple interface separately. Suppose the following scenario: BSS_1 and GO_1 on channel X, and BSS_2 and GO_2 on channel Y. Now BSS_1 receives channel switch (count 5 -> channel Z) and the user space decides to move GO_1 (only). Slightly later, when the previous channel switch is still in progress BSS_2 also receives a channel switch, so wpa_s would try to trigger GO_2's CSA, which is impossible because there's already a "merged CSA" in progress. So the best way here is to send a separate CSA command for each interface and let the kernel decide how to perform the switch. The merged API is ok with me, but it should leave the option to switch separately (with little delays). -----Original Message----- From: Luca Coelho [mailto:luca@xxxxxxxxx] Sent: Thursday, January 23, 2014 09:32 To: Michal Kazior Cc: Johannes Berg; linux-wireless; Otcheretianski, Andrei Subject: Re: [PATCH 5/7] mac80211: improve CSA locking (adding Andrei, since he should be aware of these discussions as well ;) On Thu, 2014-01-23 at 07:41 +0100, Michal Kazior wrote: > On 23 January 2014 07:31, Luca Coelho <luca@xxxxxxxxx> wrote: > > On Thu, 2014-01-23 at 07:22 +0100, Michal Kazior wrote: > >> On 22 January 2014 16:13, Luca Coelho <luca@xxxxxxxxx> wrote: > >> > On Wed, 2014-01-22 at 16:10 +0100, Johannes Berg wrote: > >> >> On Wed, 2014-01-22 at 14:36 +0200, Luca Coelho wrote: > >> >> > >> >> > 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). > >> >> > >> >> Do you mean that we shouldn't even have all that new API to > >> >> switch multiple interfaces simultaneously? > >> > > >> > Right, I'm not really sure it's necessary. PErhaps with > >> > non-chanctx we need something like that, but maybe it would still > >> > be better not to do this in the nl80211 API, but sync/merge in cfg80211/mac80211? > >> > >> I was thinking about it. This should work, mostly, as long as > >> you're able to submit CSA requests fast enough and you don't use > >> count 0 or 1, in which case it becomes racy. > > > > CSA with count 0 or 1 are really tricky in many respects. But still > > I don't see why it would get racy. The interfaces will switch > > independently, making their own chanctx reservations and so on... > > You can't really switch multiple interfaces independently with a > single-channel hardware. You'll either end up with some interfaces > disconnected or dragged to a different channel forcefully. Right... I think there's no way around dragging them all forcefully. What about this: when mac80211 sees that one interface is about to switch channel and there are other interfaces in a single-channel device, it automatically starts channel switch on the other interfaces as well (really, there's no way around it). Obviously it needs to inform userspace in this case and then it's up to the userspace to decide what to do (drop the connection, or accept the change). In multi-channel interfaces, we don't switch automatically, but let the userspace decide what to do with the other interfaces. If it doesn't do anything, we end up with each interface on a different channel. Actually this could be generalized too. We don't switch automatically only when we have single-channel interfaces, but when we don't have a free context for the new channel. -- Luca. --------------------------------------------------------------------- A member of the Intel Corporation group of companies This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. ��.n��������+%������w��{.n�����{���zW����ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
