Re: off- & multi-channel operation

[Ben Greear <greearb@candelatech.com>]

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@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com