On Mon, 2012-02-27 at 16:10 +0100, Dave Taht wrote: > On Mon, Feb 27, 2012 at 12:49 PM, Johannes Berg > <johannes@xxxxxxxxxxxxxxxx> 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 -- 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
