On Wed, 2007-06-13 at 13:34 +0200, Patrick McHardy wrote: > > The key argument for Jamal's solution is the NIC will send out 32 > > packets in the full PHL in a reasonably short time (a few microsecs > per > > Jamal's calculation). But for wireless, the PHL hardware has low > > probability to seize the wireless medium when there are full of high > > priority frames in the air. That is, the chance for transmission in > PHL > > and PHH is not equal. Queuing packets in software will starve high > > priority packets than putting them to PHH as early as possible. > > > Well, the key result of our discussion was that it makes no difference > wrt. queuing behaviour if the queue wakeup strategy is suitable chosen > for the specific queueing discipline, but it might add some overhead.
My point is the overhead is hugh for the wireless case which causes it unacceptable. Given the above example in wireless medium, which queue wakeup strategy will you choose? I guess it might be the "not stop tx ring + requeue"? If this is selected, when there is a low priority packet coming (PHL is full), the Qdisc will keep dequeue and requeue for the same packet for a long time (given the fact of wireless medium) and chew tons of CPU. We met this problem before in our driver and this (not stop tx ring + requeue) is not a good thing to do. Thanks, -yi - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
