On 11/11/2011 02:13 AM, Johannes Berg wrote:
On Wed, 2011-11-09 at 11:54 -0800, Ben Greear wrote:
However, it's not really going to work well for multi-channel capable
drivers: say the driver is continually switching between channels 1 and
11 for multi-channel operation, but now you want to do a p2p listen
phase on channel 6. That needs to interact with the driver since it has
to stop switching, and it'd be much easier to have the driver manage
that interaction.
If mac80211 is controlling the channel switching with off-channel work
items, can't it just keep the nic on channel 6 doing the p2p listen
for the proper amount of time? Why does the driver have to make
the decision?
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).
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.
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.
Thanks,
Ben
--
Ben Greear <greearb@xxxxxxxxxxxxxxx>
Candela Technologies Inc http://www.candelatech.com
--
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
