ixgbe(1)

NAME
ixgbe -This file describes the Linux* Base Driver for the 10 Gigabit Family of Adapters.

SYNOPSIS
modprobe ixgbe [<option>=<VAL1>,<VAL2>,...]

DESCRIPTION
This driver is intended for 2.6.x or later kernels. A version of the driver may already be included by your distribution and/or the kernel.org kernel. This driver includes support for any 64 bit Linux supported system, x86_64, PPC64, ARM, etc.

This driver is only supported as a loadable module at this time. Intel is not supplying patches against the kernel source to allow for static linking of the drivers. For questions related to hardware requirements, refer to the documentation supplied with your Intel adapter. All hardware requirements listed apply to use with Linux.

OPTIONS
The following optional parameters are used by entering them on the command line with the modprobe command. For example:

    modprobe ixgbe InterruptThrottleRate=16000,16000

RSS

    Valid Range: 0-16

    0 = Assign up to the lesser value of the number of CPUs or the number of queues

    X = Assign X queues, where X is less than or equal to the maximum number of queues (16 queues).

    RSS also affects the number of transmit queues allocated on 2.6.23 and newer kernels with CONFIG_NETDEVICES_MULTIQUEUE set in the kernel .config file. CONFIG_NETDEVICES_MULTIQUEUE only exists from 2.6.23 to 2.6.26. Other options enable multiqueue in 2.6.27 and newer kernels.

MQ - Multiqueue

Valid Range: 0, 1

    0 = Disables Multiple Queue support 1 = Enabled Multiple Queue support (a prerequisite for RSS)

Direct Cache Access (DCA)

    Valid Range: 0, 1

    0 = Disables DCA support in the driver

    1 = Enables DCA support in the driver

    If the driver is enabled for DCA, this parameter allows load-time control of the feature.

    Note: DCA is not supported on X550-based adapters.

IntMode

    Valid Range: 0-2 (0 = Legacy Int, 1 = MSI and 2 = MSI-X)

    IntMode controls the allowed load time control over the type of interrupt registered for by the driver. MSI-X is required for multiple queue support, and some kernels and combinations of kernel .config options will force a lower level of interrupt support.

InterruptThrottleRate

    Valid Range: 0=off 1=dynamic <min_ITR>-<max_ITR>

    Interrupt Throttle Rate controls the number of interrupts each interrupt vector can generate per second. Increasing ITR lowers latency at the cost of increased CPU utilization, though it may help throughput in some circumstances.

    0 = Setting InterruptThrottleRate to 0 turns off any interrupt moderation
      and may improve small packet latency. However, this is generally not
      suitable for bulk throughput traffic due to the increased CPU utilization
      of the higher interrupt rate.
      NOTES:
      - On 82599, and X540, and X550-based adapters, disabling InterruptThrottleRate
        will also result in the driver disabling HW RSC.
      - On 82598-based adapters, disabling InterruptThrottleRate will also
        result in disabling LRO (Large Receive Offloads).

    1 = Setting InterruptThrottleRate to Dynamic mode attempts to moderate
      interrupts per vector while maintaining very low latency. This can
      sometimes cause extra CPU utilization. If planning on deploying ixgbe
      in a latency sensitive environment, this parameter should be considered.

    <min_ITR>-<max_ITR> = 956-488281
      Setting InterruptThrottleRate to a value greater or equal to <min_ITR>
      will program the adapter to send at most that many interrupts
      per second, even if more packets have come in. This reduces interrupt load
      on the system and can lower CPU utilization under heavy load, but will
      increase latency as packets are not processed as quickly.

LLIPort

    Valid Range: 0-65535

    LLI is configured with the LLIPort command-line parameter, which specifies which TCP port should generate 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.

    WARNING: Enabling LLI can result in an excessive number of interrupts/second that may cause problems with the system and in some cases may cause a kernel panic. Note: LLI is not supported on X550-based adapters.

LLIPush

    Valid Range: 0-1

    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. Note: LLI is not supported on X550-based adapters.

LLISize

    Valid Range: 0-1500

    LLISize causes an immediate interrupt if the board receives a packet smaller than the specified size. Note: LLI is not supported on X550-based adapters. LLIEType

    Valid Range: 0-0x8FFF

    This parameter specifies the Low Latency Interrupt (LLI) Ethernet protocol type. Note: LLI is not supported on X550-based adapters. LLIVLANP -------- Valid Range: 0-7 This parameter specifies the LLI on VLAN priority threshold. Note: LLI is not supported on X550-based adapters. FdirPballoc

    Valid Range: 1-3

    Specifies the Intel(R) Ethernet Flow Director allocated packet buffer size. 1 = 64k 2 = 128k 3 = 256k

    Valid Range: 0-255

    This parameter is used with the Intel Ethernet Flow Director and is the software ATR transmit packet sample rate. For example, when AtrSampleRate is set to 20, every 20th packet looks to see if the packet will create a new flow. A value of 0 indicates that ATR should be disabled and no samples will be taken.

LRO

    Valid Range: 0(off), 1(on) Large Receive Offload (LRO) is a technique for increasing inbound throughput of high-bandwidth network connections by reducing CPU overhead. It works by aggregating multiple incoming packets from a single stream into a larger buffer before they are passed higher up the networking stack, thus reducing the number of packets that have to be processed. LRO combines multiple Ethernet frames into a single receive in the stack, thereby potentially decreasing CPU utilization for receives. This technique is also referred to as Hardware Receive Side Coalescing (HW RSC). 82599, X540, and X550-based adapters support HW RSC. The LRO parameter controls HW RSC enablement.

    You can verify that the driver is using LRO by looking at these counters in ethtool:

- hw_rsc_aggregated - counts total packets that were combined

- hw_rsc_flushed - counts the number of packets flushed out of LRO

    NOTE: IPv6 and UDP are not supported by LRO.

MDD (Malicious Driver Detection)

    Valid Range: 0-1

    0 = Disabled

    1 = Enabled

    This parameter is only relevant for devices operating in SR-IOV mode. When this parameter is set, the driver detects malicious VF driver and disables its Tx/Rx queues until a VF driver reset occurs.

Jumbo Frames

    Jumbo Frames support is enabled by changing the Maximum Transmission Unit (MTU) to a value larger than the default value of 1500.

    Use the ip command to increase the MTU size. For example, enter the following where <ethX> is the interface number:

    # ip link set mtu 9000 dev <ethX>

    # ip link set up dev <ethX>

NOTE: The maximum MTU setting for jumbo frames is 9710. This corresponds to the maximum jumbo frame size of 9728 bytes. NOTE: This driver will attempt to use multiple page sized buffers to receive each jumbo packet. This should help to avoid buffer starvation issues when allocating receive packets. NOTE: Packet loss may have a greater impact on throughput when you use jumbo frames. If you observe a drop in performance after enabling jumbo frames, enabling flow control may mitigate the issue. NOTE: For 82599-based network connections, if you are enabling jumbo frames in a virtual function (VF), jumbo frames must first be enabled in the physical function (PF). The VF MTU setting cannot be larger than the PF MTU. See the section "Jumbo Frames" in the Readme.

SUPPORT

For additional information regarding building and installation, see the README included with the driver. For general information, go to the Intel support website at: http://www.intel.com/support/

If an issue is identified with the released source code on a supported kernel with a supported adapter, email the specific information related to the issue to e1000-devel@lists.sf.net.