Multiqueue netwrok device support implementation.

- Added a loadable parameter "multiq" to enable/disable multiqueue support,

  by default it is disabled.

- skb->queue_mapping is not used for queue/fifo selection. FIFO iselection is

  based on IP-TOS value, 0x0-0xF TOS values are mapped to 8 FIFOs.

- Added per FIFO flags FIFO_QUEUE_START and FIFO_QUEUE_STOP. Check this flag

  for starting and stopping netif queue and update the flags accordingly.

- In tx_intr_handler added a check to ensure that we have free TXDs before wak-

  ing up the queue.

- Added helper functions for queue manipulation(start/stop/wakeup) to invoke

  appropriate netif_ functions.

- Calling netif_start/stop for link up/down case respectively.
Signed-off-by: Surjit Reang <surjit.reang@neterion.com>

Signed-off-by: Sreenivasa Honnur <sreenivasa.honnur@neterion.com>

---

diff -Nurp orig/drivers/net/s2io.c patch1/drivers/net/s2io.c

--- orig/drivers/net/s2io.c	2007-12-21 12:10:29.000000000 -0800

+++ patch1/drivers/net/s2io.c	2007-12-21 13:36:59.000000000 -0800

@@ -50,6 +50,8 @@

  *                 Possible values '1' for enable , '0' for disable.

  *                 Default is '2' - which means disable in promisc mode

  *                 and enable in non-promiscuous mode.

+ * multiq: This parameter used to enable/disable MULTIQUEUE support.          *

+ *      Possible values '1' for enable and '0' for disable. Default is '0'    *

  ************************************************************************/
 #include <linux/module.h>

@@ -84,7 +86,7 @@

 #include "s2io.h"

 #include "s2io-regs.h"
-#define DRV_VERSION "2.0.26.15-2"

+#define DRV_VERSION "2.0.26.16"
 /* S2io Driver name & version. */

 static char s2io_driver_name[] = "Neterion";

@@ -93,6 +95,12 @@ static char s2io_driver_version[] = DRV_

 static int rxd_size[2] = {32,48};

 static int rxd_count[2] = {127,85};
+#ifdef CONFIG_NETDEVICES_MULTIQUEUE

+/* mapping from tos value to fifo number

+ * 0x0-0xF TOS values are m...
[ message continues ]

Standard way to use that would be using skb->priority
But I'm surprised you bother with TOS for multi queues at all. TOS

isn't a too important mechanism.
I would have thought the primary use case would be per CPU TX completion

interrupts. With that the queue should be selected based on

the the current CPU.
-Andi

--

[Ram] Thanks. We can use this field to determine the priority. It should

[Ram] Agreed TOS is not too important. The purpose of this patch was to

add the multiqueue functionality with a feature that can use it. With

multiple transmit fifos enabled, a whole new set of features that can be

[Ram] I am assuming that this is with regards to msi-x interrupts. We

have done away with handling tx completion in the interrupt handler, and

are instead handling them in the context of the transmit. The slow path,

straggling transmit completions will be handled in the timer context.

This patch (along with other new features) will be sent soon.
--

> [Ram] I am assuming that this is with regards to msi-x interrupts. We
Yes. 
Ok -- hopefully you don't have bad corner cases from this when the pipe

is not fully filled and then causing longer latencies on completion.

Old NAPI sometimes suffered from such problems. 
-Andi

--

> > [Ram] I am assuming that this is with regards to msi-x interrupts.

[Ram] We have hit the driver pretty hard during testing and have not

encountered any problems either on the network or host.
--

From: Andi Kleen <andi@firstfloor.org>
BTW, such a TX completion timer will stall TCP sockets when the TX

queue of the device is partially filled and then sending stops.
TX ring SKB liberation really must be done in a very small finite

amount of time in order to avoid this problem properly.
Deferring it to HZ granular timers doesn't give a quick enough

response, especially at high packet rates.

--

> From: netdev-owner@vger.kernel.org

[Ram] We could add a lower granular tx completion interrupt instead, to

handle all the transmit fifos. But this will be a fall back in the event

the completions do not happen in the context of the transmit.
Ram

--

thanks, at a quick glance, the use of the new multi-queue APIs look ok.

  I'll give it another in-depth look and merge it.
--