Return-path: Received: from emh07.mail.saunalahti.fi ([62.142.5.117]:40552 "EHLO emh07.mail.saunalahti.fi" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751157AbaAWJuw (ORCPT ); Thu, 23 Jan 2014 04:50:52 -0500 Message-ID: <1390470648.4189.88.camel@porter.coelho.fi> (sfid-20140123_105057_777863_06EF11D7) Subject: Re: [PATCH 5/7] mac80211: improve CSA locking From: Luca Coelho To: Michal Kazior Cc: Johannes Berg , linux-wireless , "Otcheretianski, Andrei" Date: Thu, 23 Jan 2014 11:50:48 +0200 In-Reply-To: References: <1390227670-19030-1-git-send-email-michal.kazior@tieto.com> <1390227670-19030-6-git-send-email-michal.kazior@tieto.com> <1390316761.6199.27.camel@jlt4.sipsolutions.net> <1390380726.4334.4.camel@jlt4.sipsolutions.net> <1390382020.4334.17.camel@jlt4.sipsolutions.net> <1390385995.4334.27.camel@jlt4.sipsolutions.net> <1390394166.4189.28.camel@porter.coelho.fi> <1390403432.4334.33.camel@jlt4.sipsolutions.net> <1390403634.4189.39.camel@porter.coelho.fi> <1390458664.4189.48.camel@porter.coelho.fi> <1390462306.4189.56.camel@porter.coelho.fi> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Sender: linux-wireless-owner@vger.kernel.org List-ID: On Thu, 2014-01-23 at 08:57 +0100, Michal Kazior wrote: > On 23 January 2014 08:31, Luca Coelho wrote: > > (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 wrote: > >> > On Thu, 2014-01-23 at 07:22 +0100, Michal Kazior wrote: > >> >> On 22 January 2014 16:13, Luca Coelho 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). > > This is actually the tricky part. How do you automatically switch an > AP interface? You should be able to at least generate CSA IE - true - > but what about beacon after CSA? You need to update HT IE and VHT IE > at least. Good point, so instead of doing it automatically, we send a notification that says "switch or die". Then userspace needs to request the switch or drop. > Perhaps we could split CSA into two parts somehow and make it more > userspace coordinated. The first part of CSA - announcing it, is > trivial and can actually be done entirely within mac80211 if I'm not > mistaken. What needs userspace input is what happens after the > announcement. This would mean that there is a possible time gap > between announcement being completed and the actual channel switch & > operation resuming. Yeah, this is similar to what I was thinking about while replying to the other thread. > This approach would also help with case of handling CSA to a DFS > "usable" channel that needs a CAC first. The CAC might take too long. If we have an AP1 and a STA and the STA gets the CSA from its AP2 with a short count, AP1 may not have the time to CAC. In this case, AP1 have two choices: trust that AP2 is doing the right thing and moving to a usable DFS channel or shut itself down. Still, we leave the final decision to the userspace. The only thing mac80211 can know for sure is that all the interfaces in that channel must "switch or die". -- Luca.