Re: mac80211 queue handling in multi-channel

[Richard Farina <sidhayn@gmail.com>]

On 03/26/12 12:13, Johannes Berg wrote:
> So I've started to work on this a bit.
>
> On Mon, 2012-02-27 at 12:49 +0100, Johannes Berg wrote:
>
>> So what changes would this require?
>>
>> First of all, of course the driver needs to advertise the number of
>> hardware queues it supports. We'll have to think about changing the
>> check "do we support QoS" from "hw.queues >= 4" to something else, but I
>> think >=4 will still be a good indication and it seems unlikely that
>> somebody will have a device with a lot of queues yet not support QoS.
> This is a non-issue really.
>
>> Then of course, the driver needs to tell mac80211 about queue mapping.
>> For this, there's one global queue:
>>  * off-channel TX queue
>> Additionally, there are per-interface queues:
>>  * 4 per AC
>>  * CAB for this interface
> This I haven't gotten to.
>
> One issue I noticed though is that the queue mapping might need to be
> changed during the lifetime of the virtual interface (ie. while it's
> UP).
>
> Over in the other thread, I'm discussing channel contexts with Michal,
> and it seems that when the channel context is changed the queue mapping
> might also change. This doesn't seem like a problem, but we definitely
> need to keep it in mind. The way to handle it would be to stop the
> netdev queues, sync_net(), drop everything we have queued up for this
> interface and then we have clean state to start from.
>
>
> The other thing this affects is monitor mode. When the hardware queues
> are only defined per interface, we can't just give a frame to the driver
> on an essentially random queue and hope it can transmit it. Therefore,
> we need more queues, for monitor mode, in some way.
>
> As I was also trying to figure out what a good way to handle monitor
> mode in cases like iwlwifi is where the device really wants to be in a
> special "monitor mode" -- not just different filter programming.
>
> So to address both of these things, I came up with this patch:
> http://p.sipsolutions.net/ad87702d716df6d5.txt
>
> This will allow drivers to be informed of monitor mode when that is the
> only thing active.
>
> Injection would work like this:
>  * when monitor is only active:
>   - use this pseudo monitor interface
>   - if that doesn't exist (driver doesn't have it): discard frame
>  * when something else is active:
>   - if the TA of the injected frame matches any vif: use that vif
>   - if the TA doesn't match: use a vif matching the monitor addr
>   - if that doesn't exist: discard frame
>
>
> I think this strikes a good balance between having injection and having
> to worry about it too much. Obviously, drivers not implementing this new
> monitor mode interface capability wouldn't have pure injection, but that
> seems OK -- it should be relatively easy to add this to drivers.
This all seems very sane to me, I don't have any complaints to register. 
> As mentioned in the patch, the alternative would be to have new API for
> all of this, but that doesn't seem worthwhile.
Agreed

thanks,
Rick
>
> johannes
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>