On Tue, Jul 29, 2008 at 4:46 PM, Johannes Berg <johannes@xxxxxxxxxxxxxxxx> wrote: > On Tue, 2008-07-29 at 16:43 +0300, Tomas Winkler wrote: > >> No the mistake is on your side. FIFO is not relevant here. What is >> important is whether HW queue is full or not. >> Except the AC Back off scheduling done by FIFO there is BA protocol >> which my stall HW queue. It doesn't mean that other packets with the >> same FIFO should be stalled. You need additional SW queue that can be >> stopped. > > HW queues are irrelevant, you're the only vendor that implements it with > HW queues. If you think they're required for correct operation, clearly > you're wrong. Please put some reasoning behind this 'wrong'? Different doesn't mean wrong and 'only one' certainly doesn't mean wrong. And it also doesn't mean that this hw should not operates correctly under Linux. I also cannot publish any performance comparison but it doesn't look wrong at all. If Intel is the only vendor implements this that way that we may push the extra queuing into driver but so far I've seen only athk9 with 11n. > I'm just trying to fix the bugs and find a way to do this with hardware > that doesn't have extra HW queues. I don't want to even answer to this. Tomas -- 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
