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. As mentioned in the patch, the alternative would be to have new API for all of this, but that doesn't seem worthwhile. 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
