Search Linux Wireless

Re: [PATCH 5/7] mac80211: improve CSA locking

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



(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.

--
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




[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Wireless Personal Area Network]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite Hiking]     [MIPS Linux]     [ARM Linux]     [Linux RAID]

  Powered by Linux