RE: [PATCH 1/1]ixgbe: Driver for Intel 82598 based 10GbE PCI Express family of adapters

2007-07-27 Thread Veeraiyan, Ayyappan
>-Original Message-
>From: Jeff Garzik [mailto:[EMAIL PROTECTED]
>Veeraiyan, Ayyappan wrote:
>> So, with driver/device supporting multiple Tx and Rx queues, I think,
it
>> would be very useful to have ethtool interface to manage the number
of
>> Tx and Rx queues of the interface.
>
>
>Absolutely!  ethtool patches welcome :)
>
>git://git.kernel.org/pub/scm/network/ethtool/ethtool.git
>

We discussed this here today and we will try to come up with patches.

Also, FWIW, I will be offline for next 2 months, and someone (Auke ? :))
from our team will submit updated driver shortly..

Ayyappan
-
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


Re: [PATCH 1/1]ixgbe: Driver for Intel 82598 based 10GbE PCI Express family of adapters

2007-07-27 Thread Jeff Garzik

Veeraiyan, Ayyappan wrote:

So, with driver/device supporting multiple Tx and Rx queues, I think, it
would be very useful to have ethtool interface to manage the number of
Tx and Rx queues of the interface.



Absolutely!  ethtool patches welcome :)

git://git.kernel.org/pub/scm/network/ethtool/ethtool.git

Jeff


-
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


RE: [PATCH 1/1]ixgbe: Driver for Intel 82598 based 10GbE PCI Express family of adapters

2007-07-27 Thread Veeraiyan, Ayyappan
>-Original Message-
>From: Jeff Garzik [mailto:[EMAIL PROTECTED]
>
>Stephen Hemminger wrote:
>> Using module parameter for per device settings is bad idea.
>> Please extend existing interfaces like ethtool, etc rather than
>committing
>> to a bad inflexible API.
>
>
>I agreed with Stephen's comments here.
>
>In general, net driver policy is to use ethtool (per-interface
>granularity) rather than module options.
>

Thanks Stephen and Jeff for the feedback. The flow control and
InterruptThrottleRate parameters were carried over from e1000 and it was
pointed out to me that some disros/customer's scripts used those
parameters in the scripts. Ixgbe being a new driver, we can remove
those.

Yes the LLI parameters can be removed.

> +RxQueues
> +
> +Valid Range: 1, 2, 4, 8
> +Default Value: 8
> +Number of RX queues.
> +
> +

Ok. The present driver being NAPI only and supports one Rx queue only.
So this parameter needs to be removed .

But, once we have DaveM/Stephen work of NAPI struct work is done, driver
will support multiple Rx queues and with Multi Tx queue patch already in
the kernel, driver will support multiple Tx queues also shortly.

So, with driver/device supporting multiple Tx and Rx queues, I think, it
would be very useful to have ethtool interface to manage the number of
Tx and Rx queues of the interface. Current ethtool interface supports
managing the ring size so, we need similar interface for managing the
number of Tx and Rx queues of the interface.

Ayyappan
-
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


Re: [PATCH 1/1]ixgbe: Driver for Intel 82598 based 10GbE PCI Express family of adapters

2007-07-27 Thread Jeff Garzik

Stephen Hemminger wrote:

Using module parameter for per device settings is bad idea.
Please extend existing interfaces like ethtool, etc rather than committing
to a bad inflexible API.



I agreed with Stephen's comments here.

In general, net driver policy is to use ethtool (per-interface 
granularity) rather than module options.


Jeff


-
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


Re: [PATCH 1/1]ixgbe: Driver for Intel 82598 based 10GbE PCI Express family of adapters

2007-07-26 Thread Stephen Hemminger



+
+Command Line Parameters
+===
+
+If the driver is built as a module, the  following optional parameters are
+used by entering them on the command line with the modprobe command using
+this syntax:
+
+ modprobe ixgbe [=,,...]
+
+For example, with two PRO/10GbE PCI Express adapters, entering:
+
+ modprobe ixgbe TxDescriptors=80,128
+
+loads the ixgbe driver with 80 TX resources for the first adapter and 128 TX
+resources for the second adapter.
+
+The default value for each parameter is generally the recommended setting,
+unless otherwise noted.
+
+
+RxQueues
+
+Valid Range: 1, 2, 4, 8
+Default Value: 8
+Number of RX queues.
+   
+

+RxFCHighThresh
+--
+Valid Range: 1,536 - 262,136 (0x600 - 0x3FFF8, 8 byte granularity)
+Default Value: 196,608 (0x3)
+Receive Flow control high threshold (when we send a pause frame)
+
+
+RxFCLowThresh
+-
+Valid Range: 64 - 262,136 (0x40 - 0x3FFF8, 8 byte granularity)
+ *  must be less than high threshold by at least 8 bytes
+Default Value:  163,840 (0x28000)
+Receive Flow control low threshold (when we send a resume frame)
  

Does this really need to be tunable?

+
+
+RxBufferMode
+
+Valid Range: 0-2
+Default Value: 2
+0 = Driver will use single buffer for Rx packets.
+1 = Driver will use packet split mode for Rx. Packet header will be 
+received in header buffer and payload will be received in data buffer.
+2. = Optimal mode. Driver will use single buffer mode for non-Jumbo 
+configurations and packet split mode for Jumbo configurations.

+
+
+InterruptType
+-
+Valid Range: 0-2 0 = Legacy Int, 1 = MSI and 2 = MSIX
+Default Value: 2
+Interrupt type
  

Bogus, just do it.

+
+
+FCReqTimeout
+
+Valid Range: 1 - 65535
+Default Value:  65535 (0x) (will send an xon if we recover)
+Flow control request timeout (how long to pause the link partner's tx)
+
  

Extend ethtool?

+
+InterruptThrottleRate
+-
+Valid Range: 100-10 (0=off, 1=dynamic)
+Default Value: 
+Interrupt Throttle Rate (interrupts/sec)
  

Use ethtool for this

+
+
+FlowControl
+---
+Valid Range: 0-3
+0 - No Flow Control
+1 - Rx only, respond to PAUSE frames but do not generate them
+2 - Tx only, generate PAUSE frames but ignore them on receive
+3 - Full Flow Control Support
+Default Value: 1 - Rx only 
+User Specified Flow Control Override

+
  

Use ethtool, no module parameter please

+
+LLIPort
+---
+Valid Range: 0 - 65535
+Default Value: 0 (disabled)
+
+  LLI is configured with the LLIPort command-line parameter, which specifies 
+  which TCP should general Low Latency Interrupts.

+
+  For example, using LLIPort=80 would cause the board to generate an 
+  immediate interrupt upon receipt of any packet sent to TCP port 80 on the 
+  local machine.

+
  
This seems like a bogus feature, it is very protocol specific, and won't 
work

with encapsulation, and probably not IPV6.

+
+LLIPush
+---
+Valid Range: 0-1
+Default Value: 0 (disabled)
+
+  LLIPush can be set to be enabled or disabled (default). It is most 
+  effective in an environment with many small transactions.

+  NOTE: Enabling LLIPush may allow a denial of service attack.
  


Extend ethtool instead?

+
+
+LLISize
+---
+Valid Range: 0-1500
+Default Value: 0 (disabled)
+
+  LLISize causes an immediate interrupt if the board receives a packet smaller 
+  than the specified size.
  

Another odd hardware feature. Just because hardware supports it,
you don't have to have driver support.

+
+
+Support
+===
+
+For general information, go to the Intel support website at:
+
+http://support.intel.com
+
+or the Intel Wired Networking project hosted by Sourceforge at:
+
+http://sourceforge.net/projects/e1000
+
+If an issue is identified with the released source code on the supported
+kernel with a supported adapter, email the specific information related
+to the issue to [EMAIL PROTECTED]
  

Using module parameter for per device settings is bad idea.
Please extend existing interfaces like ethtool, etc rather than committing
to a bad inflexible API.

-
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