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. 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. > To recap: today, almost all drivers expose four queues to mac80211 for > the four ACs. In reality, many have many more queues, e.g. in iwlwifi: > * 4 for the first vif > * 4 for the second vif > * 1 for CAB (content after [DTIM] beacon) > * 1 for off-channel > > They are mapped as follows: > * all vif ACs -> 4 ACs > * off-channel -> BE > * CAB -> BE (I believe, maybe all?) > > 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. -- Dave Täht SKYPE: davetaht US Tel: 1-239-829-5608 http://www.bufferbloat.net -- 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
