On Fri, 2011-11-11 at 09:54 -0800, Ben Greear wrote: > > mac80211 isn't going to be controlling the switching between 1 and 11 at > > all though. And there will be drivers like iwlwifi and wl12xx that want > > to control the "stay on channel 6" as well. > > But at least for ath9k, it certainly *could* do this. If other NICs > cannot handle this for whatever reason, then they can be handled some > other way. It would seem to me that mac80211 is going to have a better > picture on what needs doing than the driver (it can see software queues, > all network-devices, the upper network stack if needed, etc). It could, but it won't be efficient. mac80211 mostly does everything in workqueues, and this is rather timing sensitive so you want to do it closer to the hardware, possibly even in the interrupt handler that tells you to switch (you could program the timers in the hardware for that) > >> If you expect the driver might have pkts queued for multiple channels, > >> and that is why it would be switching, then you could just have a mac80211 > >> call that says 'stay on this channel (6) until I tell you otherwise'. > >> The driver could then stop it's automated switching. That would seem > >> fairly easy to implement. > > > > Yes, that's what we'll probably need. Actually we already have that in a > > way with the remain_on_channel, but it's not used for work/scan/etc. > > today, only for p2p. > > So, I'm suggesting we put this functionality into the work logic. It's > already doing half-assed on/off channel stuff, as is scan, and it seems > as p2p or other off-channel stations needs as well. Lets put it all in one > place, and then optimize it to work well. We could batch work-items for > the same channel together, for instance, and handle the on/off channel > switching so that the stations get enough time to do useful work on their > channel. That works mostly, but not for actual operation on multiple channels. > >> Worst case, you flush all buffers and > >> then it should certainly stop switching? (The hard part would seem to be making the > >> driver able to deal with multiple xmit queues and doing automated > >> switching in the first place. It certainly never worked well when > >> ath9k tried to do something similar with virtual phys) > > > > At least for iwlwifi I expect we'd have multiple hardware queues with > > the uCode handling the switching. > > So if the NIC can do everything, then maybe send work-items to it and let > it do the scheduling? Like: 'spend max of 200ms on this channel and send/rcv as > many pkts as possible', or 'scan this channel for 20ms', or 'do-full-hw-scan'. > If the NIC wants to hop channels on it's own, the off-channel work items could > be considered suggestions and let the NIC schedule how it wants. That's kinda how it works now, but not all NICs can even handle that. Think wl1251 or iwlegacy for example, it'll never support all of these features of course but it also doesn't deal well with the channel switching work items we have today. johannes -- 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
