Re: [PATCH] NET: Multiqueue network device support.

[Zhu Yi <yi.zhu@intel.com>]

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