From: jamal <hadi@xxxxxxxxxx> Date: Sun, 20 Jul 2008 18:32:50 -0400 > pfifo_fast would be a bad choice in that case, but even a pfifo cannot > guarantee proper RR because it would present packets in a FIFO order > (and example the first 10 could go to hardware queue1 and the next to > hardware queue2). Jamal, I have to wonder why are you so hung up on matching our software qdiscs with whatever fairness algorithm the hardware happens to implement internally for the TX queues? Every time this topic comes up, you insist on them having to match. And I have no idea why. It's largely irrelevant and the TX queue can be viewed purely as a buffer between us and the device, nearly a black hole we stick packets into. > > These things are built for parallelization, not prioritization. > > Total parallelization happens in the ideal case. If X cpus classify > packets going to X different hardware queueus each CPU grabs only locks > for that hardware queue. The problem is that the bottleneck is the qdisc itself since all those cpus synchonize on it's lock. We can't have a shared qdisc for the device and get full parallelization. That's why we're having one qdisc per TX queue, so that they all don't bunch up on the qdisc lock. Otherwise, there is zero point in all of these TX multiqueue features in the hardware if we can't parallelize things fully. -- 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
