Re: [RFT/FYI] mac80211: revert on-channel work optimisations

[Ben Greear <greearb@candelatech.com>]

On 11/08/2011 09:56 AM, Johannes Berg wrote:
> On Tue, 2011-11-08 at 09:25 -0800, Ben Greear wrote:
>
>> That's fine by me, I found the code complex as well.  All the tmp
>> and scan and active channel pointers makes for a real mess.
>
> Indeed.
>
>> But if
>> you want multiple vifs to work well, then you really need to be able
>> to continue to function on-channel when some other vif is scanning
>> on that channel.  My use of the wifi stack requires this to work,
>> so if it takes any significant time to get the new code in I'm going
>> to have to stick with my complex crap.
>
> And I'm not saying you shouldn't, but I think for upstream right now
> it's not really a good thing. I wish I could say otherwise but given the
> bugs we have here etc. I don't really feel very confident.

Are there any open bugs right now that seem to be because of the
scanning and work optimizations, or are you just paranoid that
there are more that are not found or well understood yet?

If there is something reported, I'll make a try at fixing it.

> Now with multi-channel stuff it's all going to change anyway, each vif
> will have its own channel and the device will have to mostly sort out
> the scheduling by itself, ath9k will have to do some tricks in the
> driver, maybe with some help in mac80211, and off-channel stuff will be
> interesting too ...

Is someone already working on this, or planning to do so soon?  At least
to me, the multi-channel stuff appears fundamentally broken since I'm
not aware of any NIC that can listen in two channels at once.  Flipping
from channel to channel seems like at best it is going to give bad latency,
and probably lots of packet loss as well.  What is the use-case for this
feature, anyway?

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com