Re: mac80211 queue handling in multi-channel

[Johannes Berg <johannes@sipsolutions.net>]

On Mon, 2012-02-27 at 16:10 +0100, Dave Taht wrote:
> On Mon, Feb 27, 2012 at 12:49 PM, Johannes Berg
> <johannes@sipsolutions.net> wrote:
> 
> > As a consequence, I'm thinking that we should redesign the mac80211 /
> > driver queue API to mirror more closely the kind of queues hardware
> > really has.
> 
> I'd like the driver queues to mirror more closely the kinds of
> connections the hardware really has. I realize that this is more of an
> AP orientation than a wireless client orientation, but with wildly
> different rates between connected devices bad things happen.

This isn't possible -- having 4 netdev queues per remote station is,
simply put, insane. We've discussed this before on this list and Eric
had a few suggestions, but I have no time to work on them. Essentially
though it boils down to solving the problem at a higher layer by
differentiating traffic to different stations.

> Secondly, my take on 802.11e QoS and wireless-n aggregation is that
> aggregation wins nearly every time; all
> 802.11e does is bloat up the buffers.

That statement doesn't really make sense to me -- QoS (on the air) and
aggregation are two unrelated things?

> > Thus when e.g. in our driver the BE queue for the second VIF is full, we
> > stop all traffic across all VIFs. When both VIFs are on the same
> > channel, this isn't really a problem. However, when they are on
> > different channels, there could be vastly different performance
> > characteristics on those two channels due to interference etc.
> 
> And even more differences based on the destination's characteristics.

I do understand that this is true, but we don't have the ability to
solve this problem at the netdev queue level.

johannes