On Fri, 23 Feb 2007 04:00:55 -0500 "Sreenivasa Honnur" <[EMAIL PROTECTED]> wrote:
> Fucntion "map_queue" returns queue index as '0'. There is no support to > return different queue indexes. > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On Behalf Of Kok, Auke > Sent: Friday, February 09, 2007 5:40 AM > To: David Miller; Garzik, Jeff; netdev@vger.kernel.org; > linux-kernel@vger.kernel.org > Cc: Kok, Auke; Peter Waskiewicz Jr; Brandeburg, Jesse; Kok, Auke; > Ronciak, John > Subject: [PATCH 1/2] NET: Multiple queue network device support > > > From: Peter Waskiewicz Jr <[EMAIL PROTECTED]> > > Added an API and associated supporting routines for multiqueue network > devices. This allows network devices supporting multiple TX queues to > configure each queue within the netdevice and manage each queue > independantly. Changes to the PRIO Qdisc also allow a user to map > multiple flows to individual TX queues, taking advantage of each queue > on the device. > > Signed-off-by: Peter Waskiewicz Jr <[EMAIL PROTECTED]> > Signed-off-by: Auke Kok <[EMAIL PROTECTED]> > --- > > +config NET_MULTI_QUEUE_DEVICE > + bool "Multiple queue network device support (EXPERIMENTAL)" > + depends on NET_SCHED && EXPERIMENTAL > + help > + Saying Y here will add support for network devices that have > more than > + one physical TX queue and/or RX queue. > + > + Multiple queue devices will require qdiscs that understand how > to > + queue to multiple targets. The default packet scheduler will > default > + to the first queue in a device. In other words, if you need > the > + ability to spread traffic across queues, your queueing > discipline > + needs to know how to do that. > + > + Note that saying Y here will give preferential treatment to > multiple > + queue devices in the network stack. A slight drop in > single-queue > + device performance may be seen. > + > + Say N here unless you know your network device supports > multiple > + TX and/or RX queues. > + This should not be a user visible configuration option. It should either: always be part of the kernel API or be selected by drivers that need/want it. -- Stephen Hemminger <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
