Jesse Brandeburg | 2115a64 | 2008-07-08 15:51:57 -0700 | [diff] [blame] | 1 | Linux Base Driver for 10 Gigabit Intel(R) Network Connection |
| 2 | ============================================================= |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 3 | |
Jesse Brandeburg | 2115a64 | 2008-07-08 15:51:57 -0700 | [diff] [blame] | 4 | October 9, 2007 |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 5 | |
| 6 | |
| 7 | Contents |
| 8 | ======== |
| 9 | |
| 10 | - In This Release |
| 11 | - Identifying Your Adapter |
Jesse Brandeburg | 2115a64 | 2008-07-08 15:51:57 -0700 | [diff] [blame] | 12 | - Building and Installation |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 13 | - Command Line Parameters |
| 14 | - Improving Performance |
Jesse Brandeburg | 2115a64 | 2008-07-08 15:51:57 -0700 | [diff] [blame] | 15 | - Additional Configurations |
| 16 | - Known Issues/Troubleshooting |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 17 | - Support |
| 18 | |
| 19 | |
Jesse Brandeburg | 2115a64 | 2008-07-08 15:51:57 -0700 | [diff] [blame] | 20 | |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 21 | In This Release |
| 22 | =============== |
| 23 | |
Jesse Brandeburg | 2115a64 | 2008-07-08 15:51:57 -0700 | [diff] [blame] | 24 | This file describes the ixgb Linux Base Driver for the 10 Gigabit Intel(R) |
| 25 | Network Connection. This driver includes support for Itanium(R)2-based |
| 26 | systems. |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 27 | |
Jesse Brandeburg | 2115a64 | 2008-07-08 15:51:57 -0700 | [diff] [blame] | 28 | For questions related to hardware requirements, refer to the documentation |
| 29 | supplied with your 10 Gigabit adapter. All hardware requirements listed apply |
| 30 | to use with Linux. |
| 31 | |
| 32 | The following features are available in this kernel: |
| 33 | - Native VLANs |
| 34 | - Channel Bonding (teaming) |
| 35 | - SNMP |
| 36 | |
| 37 | Channel Bonding documentation can be found in the Linux kernel source: |
| 38 | /Documentation/networking/bonding.txt |
| 39 | |
| 40 | The driver information previously displayed in the /proc filesystem is not |
| 41 | supported in this release. Alternatively, you can use ethtool (version 1.6 |
| 42 | or later), lspci, and ifconfig to obtain the same information. |
| 43 | |
| 44 | Instructions on updating ethtool can be found in the section "Additional |
| 45 | Configurations" later in this document. |
| 46 | |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 47 | |
| 48 | Identifying Your Adapter |
| 49 | ======================== |
| 50 | |
Jesse Brandeburg | 2115a64 | 2008-07-08 15:51:57 -0700 | [diff] [blame] | 51 | The following Intel network adapters are compatible with the drivers in this |
| 52 | release: |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 53 | |
Jesse Brandeburg | 2115a64 | 2008-07-08 15:51:57 -0700 | [diff] [blame] | 54 | Controller Adapter Name Physical Layer |
| 55 | ---------- ------------ -------------- |
| 56 | 82597EX Intel(R) PRO/10GbE LR/SR/CX4 10G Base-LR (1310 nm optical fiber) |
| 57 | Server Adapters 10G Base-SR (850 nm optical fiber) |
| 58 | 10G Base-CX4(twin-axial copper cabling) |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 59 | |
Jesse Brandeburg | 2115a64 | 2008-07-08 15:51:57 -0700 | [diff] [blame] | 60 | For more information on how to identify your adapter, go to the Adapter & |
| 61 | Driver ID Guide at: |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 62 | |
Jesse Brandeburg | 2115a64 | 2008-07-08 15:51:57 -0700 | [diff] [blame] | 63 | http://support.intel.com/support/network/sb/CS-012904.htm |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 64 | |
Jesse Brandeburg | 2115a64 | 2008-07-08 15:51:57 -0700 | [diff] [blame] | 65 | |
| 66 | Building and Installation |
| 67 | ========================= |
| 68 | |
| 69 | select m for "Intel(R) PRO/10GbE support" located at: |
| 70 | Location: |
| 71 | -> Device Drivers |
| 72 | -> Network device support (NETDEVICES [=y]) |
| 73 | -> Ethernet (10000 Mbit) (NETDEV_10000 [=y]) |
| 74 | 1. make modules && make modules_install |
| 75 | |
| 76 | 2. Load the module: |
| 77 | |
| 78 | modprobe ixgb <parameter>=<value> |
| 79 | |
| 80 | The insmod command can be used if the full |
| 81 | path to the driver module is specified. For example: |
| 82 | |
| 83 | insmod /lib/modules/<KERNEL VERSION>/kernel/drivers/net/ixgb/ixgb.ko |
| 84 | |
| 85 | With 2.6 based kernels also make sure that older ixgb drivers are |
| 86 | removed from the kernel, before loading the new module: |
| 87 | |
| 88 | rmmod ixgb; modprobe ixgb |
| 89 | |
| 90 | 3. Assign an IP address to the interface by entering the following, where |
| 91 | x is the interface number: |
| 92 | |
| 93 | ifconfig ethx <IP_address> |
| 94 | |
| 95 | 4. Verify that the interface works. Enter the following, where <IP_address> |
| 96 | is the IP address for another machine on the same subnet as the interface |
| 97 | that is being tested: |
| 98 | |
| 99 | ping <IP_address> |
| 100 | |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 101 | |
| 102 | Command Line Parameters |
| 103 | ======================= |
| 104 | |
Jesse Brandeburg | 2115a64 | 2008-07-08 15:51:57 -0700 | [diff] [blame] | 105 | If the driver is built as a module, the following optional parameters are |
| 106 | used by entering them on the command line with the modprobe command using |
| 107 | this syntax: |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 108 | |
| 109 | modprobe ixgb [<option>=<VAL1>,<VAL2>,...] |
| 110 | |
Jesse Brandeburg | 2115a64 | 2008-07-08 15:51:57 -0700 | [diff] [blame] | 111 | For example, with two 10GbE PCI adapters, entering: |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 112 | |
Jesse Brandeburg | 2115a64 | 2008-07-08 15:51:57 -0700 | [diff] [blame] | 113 | modprobe ixgb TxDescriptors=80,128 |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 114 | |
Jesse Brandeburg | 2115a64 | 2008-07-08 15:51:57 -0700 | [diff] [blame] | 115 | loads the ixgb driver with 80 TX resources for the first adapter and 128 TX |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 116 | resources for the second adapter. |
| 117 | |
| 118 | The default value for each parameter is generally the recommended setting, |
Jesse Brandeburg | 2115a64 | 2008-07-08 15:51:57 -0700 | [diff] [blame] | 119 | unless otherwise noted. |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 120 | |
| 121 | FlowControl |
| 122 | Valid Range: 0-3 (0=none, 1=Rx only, 2=Tx only, 3=Rx&Tx) |
| 123 | Default: Read from the EEPROM |
Jesse Brandeburg | 2115a64 | 2008-07-08 15:51:57 -0700 | [diff] [blame] | 124 | If EEPROM is not detected, default is 1 |
| 125 | This parameter controls the automatic generation(Tx) and response(Rx) to |
| 126 | Ethernet PAUSE frames. There are hardware bugs associated with enabling |
| 127 | Tx flow control so beware. |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 128 | |
| 129 | RxDescriptors |
| 130 | Valid Range: 64-512 |
| 131 | Default Value: 512 |
Jesse Brandeburg | 2115a64 | 2008-07-08 15:51:57 -0700 | [diff] [blame] | 132 | This value is the number of receive descriptors allocated by the driver. |
| 133 | Increasing this value allows the driver to buffer more incoming packets. |
| 134 | Each descriptor is 16 bytes. A receive buffer is also allocated for |
| 135 | each descriptor and can be either 2048, 4056, 8192, or 16384 bytes, |
| 136 | depending on the MTU setting. When the MTU size is 1500 or less, the |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 137 | receive buffer size is 2048 bytes. When the MTU is greater than 1500 the |
Jesse Brandeburg | 2115a64 | 2008-07-08 15:51:57 -0700 | [diff] [blame] | 138 | receive buffer size will be either 4056, 8192, or 16384 bytes. The |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 139 | maximum MTU size is 16114. |
| 140 | |
| 141 | RxIntDelay |
| 142 | Valid Range: 0-65535 (0=off) |
Jesse Brandeburg | 2115a64 | 2008-07-08 15:51:57 -0700 | [diff] [blame] | 143 | Default Value: 72 |
| 144 | This value delays the generation of receive interrupts in units of |
| 145 | 0.8192 microseconds. Receive interrupt reduction can improve CPU |
| 146 | efficiency if properly tuned for specific network traffic. Increasing |
| 147 | this value adds extra latency to frame reception and can end up |
| 148 | decreasing the throughput of TCP traffic. If the system is reporting |
| 149 | dropped receives, this value may be set too high, causing the driver to |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 150 | run out of available receive descriptors. |
| 151 | |
| 152 | TxDescriptors |
| 153 | Valid Range: 64-4096 |
| 154 | Default Value: 256 |
| 155 | This value is the number of transmit descriptors allocated by the driver. |
Jesse Brandeburg | 2115a64 | 2008-07-08 15:51:57 -0700 | [diff] [blame] | 156 | Increasing this value allows the driver to queue more transmits. Each |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 157 | descriptor is 16 bytes. |
| 158 | |
| 159 | XsumRX |
| 160 | Valid Range: 0-1 |
| 161 | Default Value: 1 |
| 162 | A value of '1' indicates that the driver should enable IP checksum |
| 163 | offload for received packets (both UDP and TCP) to the adapter hardware. |
| 164 | |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 165 | |
| 166 | Improving Performance |
| 167 | ===================== |
| 168 | |
Jesse Brandeburg | 2115a64 | 2008-07-08 15:51:57 -0700 | [diff] [blame] | 169 | With the 10 Gigabit server adapters, the default Linux configuration will |
| 170 | very likely limit the total available throughput artificially. There is a set |
| 171 | of configuration changes that, when applied together, will increase the ability |
| 172 | of Linux to transmit and receive data. The following enhancements were |
| 173 | originally acquired from settings published at http://www.spec.org/web99/ for |
| 174 | various submitted results using Linux. |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 175 | |
Jesse Brandeburg | 2115a64 | 2008-07-08 15:51:57 -0700 | [diff] [blame] | 176 | NOTE: These changes are only suggestions, and serve as a starting point for |
| 177 | tuning your network performance. |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 178 | |
| 179 | The changes are made in three major ways, listed in order of greatest effect: |
Jesse Brandeburg | 2115a64 | 2008-07-08 15:51:57 -0700 | [diff] [blame] | 180 | - Use ifconfig to modify the mtu (maximum transmission unit) and the txqueuelen |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 181 | parameter. |
| 182 | - Use sysctl to modify /proc parameters (essentially kernel tuning) |
Jesse Brandeburg | 2115a64 | 2008-07-08 15:51:57 -0700 | [diff] [blame] | 183 | - Use setpci to modify the MMRBC field in PCI-X configuration space to increase |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 184 | transmit burst lengths on the bus. |
| 185 | |
Jesse Brandeburg | 2115a64 | 2008-07-08 15:51:57 -0700 | [diff] [blame] | 186 | NOTE: setpci modifies the adapter's configuration registers to allow it to read |
| 187 | up to 4k bytes at a time (for transmits). However, for some systems the |
| 188 | behavior after modifying this register may be undefined (possibly errors of |
| 189 | some kind). A power-cycle, hard reset or explicitly setting the e6 register |
| 190 | back to 22 (setpci -d 8086:1a48 e6.b=22) may be required to get back to a |
| 191 | stable configuration. |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 192 | |
| 193 | - COPY these lines and paste them into ixgb_perf.sh: |
| 194 | #!/bin/bash |
Jesse Brandeburg | 2115a64 | 2008-07-08 15:51:57 -0700 | [diff] [blame] | 195 | echo "configuring network performance , edit this file to change the interface |
| 196 | or device ID of 10GbE card" |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 197 | # set mmrbc to 4k reads, modify only Intel 10GbE device IDs |
Jesse Brandeburg | 2115a64 | 2008-07-08 15:51:57 -0700 | [diff] [blame] | 198 | # replace 1a48 with appropriate 10GbE device's ID installed on the system, |
| 199 | # if needed. |
| 200 | setpci -d 8086:1a48 e6.b=2e |
| 201 | # set the MTU (max transmission unit) - it requires your switch and clients |
| 202 | # to change as well. |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 203 | # set the txqueuelen |
| 204 | # your ixgb adapter should be loaded as eth1 for this to work, change if needed |
| 205 | ifconfig eth1 mtu 9000 txqueuelen 1000 up |
Jesse Brandeburg | 2115a64 | 2008-07-08 15:51:57 -0700 | [diff] [blame] | 206 | # call the sysctl utility to modify /proc/sys entries |
| 207 | sysctl -p ./sysctl_ixgb.conf |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 208 | - END ixgb_perf.sh |
| 209 | |
| 210 | - COPY these lines and paste them into sysctl_ixgb.conf: |
| 211 | # some of the defaults may be different for your kernel |
| 212 | # call this file with sysctl -p <this file> |
| 213 | # these are just suggested values that worked well to increase throughput in |
| 214 | # several network benchmark tests, your mileage may vary |
| 215 | |
| 216 | ### IPV4 specific settings |
Jesse Brandeburg | 2115a64 | 2008-07-08 15:51:57 -0700 | [diff] [blame] | 217 | # turn TCP timestamp support off, default 1, reduces CPU use |
| 218 | net.ipv4.tcp_timestamps = 0 |
| 219 | # turn SACK support off, default on |
| 220 | # on systems with a VERY fast bus -> memory interface this is the big gainer |
| 221 | net.ipv4.tcp_sack = 0 |
| 222 | # set min/default/max TCP read buffer, default 4096 87380 174760 |
| 223 | net.ipv4.tcp_rmem = 10000000 10000000 10000000 |
| 224 | # set min/pressure/max TCP write buffer, default 4096 16384 131072 |
| 225 | net.ipv4.tcp_wmem = 10000000 10000000 10000000 |
| 226 | # set min/pressure/max TCP buffer space, default 31744 32256 32768 |
| 227 | net.ipv4.tcp_mem = 10000000 10000000 10000000 |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 228 | |
| 229 | ### CORE settings (mostly for socket and UDP effect) |
Jesse Brandeburg | 2115a64 | 2008-07-08 15:51:57 -0700 | [diff] [blame] | 230 | # set maximum receive socket buffer size, default 131071 |
| 231 | net.core.rmem_max = 524287 |
| 232 | # set maximum send socket buffer size, default 131071 |
| 233 | net.core.wmem_max = 524287 |
| 234 | # set default receive socket buffer size, default 65535 |
| 235 | net.core.rmem_default = 524287 |
| 236 | # set default send socket buffer size, default 65535 |
| 237 | net.core.wmem_default = 524287 |
| 238 | # set maximum amount of option memory buffers, default 10240 |
| 239 | net.core.optmem_max = 524287 |
| 240 | # set number of unprocessed input packets before kernel starts dropping them; default 300 |
| 241 | net.core.netdev_max_backlog = 300000 |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 242 | - END sysctl_ixgb.conf |
| 243 | |
Jesse Brandeburg | 2115a64 | 2008-07-08 15:51:57 -0700 | [diff] [blame] | 244 | Edit the ixgb_perf.sh script if necessary to change eth1 to whatever interface |
| 245 | your ixgb driver is using and/or replace '1a48' with appropriate 10GbE device's |
| 246 | ID installed on the system. |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 247 | |
Jesse Brandeburg | 2115a64 | 2008-07-08 15:51:57 -0700 | [diff] [blame] | 248 | NOTE: Unless these scripts are added to the boot process, these changes will |
| 249 | only last only until the next system reboot. |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 250 | |
| 251 | |
| 252 | Resolving Slow UDP Traffic |
| 253 | -------------------------- |
Jesse Brandeburg | 2115a64 | 2008-07-08 15:51:57 -0700 | [diff] [blame] | 254 | If your server does not seem to be able to receive UDP traffic as fast as it |
| 255 | can receive TCP traffic, it could be because Linux, by default, does not set |
| 256 | the network stack buffers as large as they need to be to support high UDP |
| 257 | transfer rates. One way to alleviate this problem is to allow more memory to |
| 258 | be used by the IP stack to store incoming data. |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 259 | |
Jesse Brandeburg | 2115a64 | 2008-07-08 15:51:57 -0700 | [diff] [blame] | 260 | For instance, use the commands: |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 261 | sysctl -w net.core.rmem_max=262143 |
| 262 | and |
| 263 | sysctl -w net.core.rmem_default=262143 |
Jesse Brandeburg | 2115a64 | 2008-07-08 15:51:57 -0700 | [diff] [blame] | 264 | to increase the read buffer memory max and default to 262143 (256k - 1) from |
| 265 | defaults of max=131071 (128k - 1) and default=65535 (64k - 1). These variables |
| 266 | will increase the amount of memory used by the network stack for receives, and |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 267 | can be increased significantly more if necessary for your application. |
| 268 | |
Jesse Brandeburg | 2115a64 | 2008-07-08 15:51:57 -0700 | [diff] [blame] | 269 | |
| 270 | Additional Configurations |
| 271 | ========================= |
| 272 | |
| 273 | Configuring the Driver on Different Distributions |
| 274 | ------------------------------------------------- |
| 275 | Configuring a network driver to load properly when the system is started is |
| 276 | distribution dependent. Typically, the configuration process involves adding |
| 277 | an alias line to /etc/modprobe.conf as well as editing other system startup |
| 278 | scripts and/or configuration files. Many popular Linux distributions ship |
| 279 | with tools to make these changes for you. To learn the proper way to |
| 280 | configure a network device for your system, refer to your distribution |
| 281 | documentation. If during this process you are asked for the driver or module |
| 282 | name, the name for the Linux Base Driver for the Intel 10GbE Family of |
| 283 | Adapters is ixgb. |
| 284 | |
| 285 | Viewing Link Messages |
| 286 | --------------------- |
| 287 | Link messages will not be displayed to the console if the distribution is |
| 288 | restricting system messages. In order to see network driver link messages on |
| 289 | your console, set dmesg to eight by entering the following: |
| 290 | |
| 291 | dmesg -n 8 |
| 292 | |
| 293 | NOTE: This setting is not saved across reboots. |
| 294 | |
| 295 | |
| 296 | Jumbo Frames |
| 297 | ------------ |
| 298 | The driver supports Jumbo Frames for all adapters. Jumbo Frames support is |
| 299 | enabled by changing the MTU to a value larger than the default of 1500. |
| 300 | The maximum value for the MTU is 16114. Use the ifconfig command to |
| 301 | increase the MTU size. For example: |
| 302 | |
| 303 | ifconfig ethx mtu 9000 up |
| 304 | |
| 305 | The maximum MTU setting for Jumbo Frames is 16114. This value coincides |
| 306 | with the maximum Jumbo Frames size of 16128. |
| 307 | |
| 308 | |
| 309 | Ethtool |
| 310 | ------- |
| 311 | The driver utilizes the ethtool interface for driver configuration and |
Jeff Kirsher | 68f20d9 | 2010-12-17 12:14:34 +0000 | [diff] [blame] | 312 | diagnostics, as well as displaying statistical information. The ethtool |
Jesse Brandeburg | 2115a64 | 2008-07-08 15:51:57 -0700 | [diff] [blame] | 313 | version 1.6 or later is required for this functionality. |
| 314 | |
| 315 | The latest release of ethtool can be found from |
Jeff Kirsher | 68f20d9 | 2010-12-17 12:14:34 +0000 | [diff] [blame] | 316 | http://ftp.kernel.org/pub/software/network/ethtool/ |
Jesse Brandeburg | 2115a64 | 2008-07-08 15:51:57 -0700 | [diff] [blame] | 317 | |
Jeff Kirsher | 68f20d9 | 2010-12-17 12:14:34 +0000 | [diff] [blame] | 318 | NOTE: The ethtool version 1.6 only supports a limited set of ethtool options. |
| 319 | Support for a more complete ethtool feature set can be enabled by |
| 320 | upgrading to the latest version. |
Jesse Brandeburg | 2115a64 | 2008-07-08 15:51:57 -0700 | [diff] [blame] | 321 | |
| 322 | |
| 323 | NAPI |
| 324 | ---- |
| 325 | |
| 326 | NAPI (Rx polling mode) is supported in the ixgb driver. NAPI is enabled |
| 327 | or disabled based on the configuration of the kernel. see CONFIG_IXGB_NAPI |
| 328 | |
| 329 | See www.cyberus.ca/~hadi/usenix-paper.tgz for more information on NAPI. |
| 330 | |
| 331 | |
| 332 | Known Issues/Troubleshooting |
| 333 | ============================ |
| 334 | |
| 335 | NOTE: After installing the driver, if your Intel Network Connection is not |
| 336 | working, verify in the "In This Release" section of the readme that you have |
| 337 | installed the correct driver. |
| 338 | |
| 339 | Intel(R) PRO/10GbE CX4 Server Adapter Cable Interoperability Issue with |
| 340 | Fujitsu XENPAK Module in SmartBits Chassis |
| 341 | --------------------------------------------------------------------- |
| 342 | Excessive CRC errors may be observed if the Intel(R) PRO/10GbE CX4 |
| 343 | Server adapter is connected to a Fujitsu XENPAK CX4 module in a SmartBits |
| 344 | chassis using 15 m/24AWG cable assemblies manufactured by Fujitsu or Leoni. |
| 345 | The CRC errors may be received either by the Intel(R) PRO/10GbE CX4 |
| 346 | Server adapter or the SmartBits. If this situation occurs using a different |
| 347 | cable assembly may resolve the issue. |
| 348 | |
| 349 | CX4 Server Adapter Cable Interoperability Issues with HP Procurve 3400cl |
| 350 | Switch Port |
| 351 | ------------------------------------------------------------------------ |
| 352 | Excessive CRC errors may be observed if the Intel(R) PRO/10GbE CX4 Server |
| 353 | adapter is connected to an HP Procurve 3400cl switch port using short cables |
| 354 | (1 m or shorter). If this situation occurs, using a longer cable may resolve |
| 355 | the issue. |
| 356 | |
| 357 | Excessive CRC errors may be observed using Fujitsu 24AWG cable assemblies that |
| 358 | Are 10 m or longer or where using a Leoni 15 m/24AWG cable assembly. The CRC |
| 359 | errors may be received either by the CX4 Server adapter or at the switch. If |
| 360 | this situation occurs, using a different cable assembly may resolve the issue. |
| 361 | |
| 362 | |
| 363 | Jumbo Frames System Requirement |
| 364 | ------------------------------- |
| 365 | Memory allocation failures have been observed on Linux systems with 64 MB |
| 366 | of RAM or less that are running Jumbo Frames. If you are using Jumbo |
| 367 | Frames, your system may require more than the advertised minimum |
| 368 | requirement of 64 MB of system memory. |
| 369 | |
| 370 | |
| 371 | Performance Degradation with Jumbo Frames |
| 372 | ----------------------------------------- |
| 373 | Degradation in throughput performance may be observed in some Jumbo frames |
| 374 | environments. If this is observed, increasing the application's socket buffer |
| 375 | size and/or increasing the /proc/sys/net/ipv4/tcp_*mem entry values may help. |
| 376 | See the specific application manual and /usr/src/linux*/Documentation/ |
| 377 | networking/ip-sysctl.txt for more details. |
| 378 | |
| 379 | |
| 380 | Allocating Rx Buffers when Using Jumbo Frames |
| 381 | --------------------------------------------- |
| 382 | Allocating Rx buffers when using Jumbo Frames on 2.6.x kernels may fail if |
| 383 | the available memory is heavily fragmented. This issue may be seen with PCI-X |
| 384 | adapters or with packet split disabled. This can be reduced or eliminated |
| 385 | by changing the amount of available memory for receive buffer allocation, by |
| 386 | increasing /proc/sys/vm/min_free_kbytes. |
| 387 | |
| 388 | |
| 389 | Multiple Interfaces on Same Ethernet Broadcast Network |
| 390 | ------------------------------------------------------ |
| 391 | Due to the default ARP behavior on Linux, it is not possible to have |
| 392 | one system on two IP networks in the same Ethernet broadcast domain |
| 393 | (non-partitioned switch) behave as expected. All Ethernet interfaces |
| 394 | will respond to IP traffic for any IP address assigned to the system. |
| 395 | This results in unbalanced receive traffic. |
| 396 | |
| 397 | If you have multiple interfaces in a server, do either of the following: |
| 398 | |
| 399 | - Turn on ARP filtering by entering: |
| 400 | echo 1 > /proc/sys/net/ipv4/conf/all/arp_filter |
| 401 | |
| 402 | - Install the interfaces in separate broadcast domains - either in |
| 403 | different switches or in a switch partitioned to VLANs. |
| 404 | |
| 405 | |
| 406 | UDP Stress Test Dropped Packet Issue |
| 407 | -------------------------------------- |
| 408 | Under small packets UDP stress test with 10GbE driver, the Linux system |
| 409 | may drop UDP packets due to the fullness of socket buffers. You may want |
| 410 | to change the driver's Flow Control variables to the minimum value for |
| 411 | controlling packet reception. |
| 412 | |
| 413 | |
| 414 | Tx Hangs Possible Under Stress |
| 415 | ------------------------------ |
| 416 | Under stress conditions, if TX hangs occur, turning off TSO |
| 417 | "ethtool -K eth0 tso off" may resolve the problem. |
| 418 | |
| 419 | |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 420 | Support |
| 421 | ======= |
| 422 | |
Jesse Brandeburg | 2115a64 | 2008-07-08 15:51:57 -0700 | [diff] [blame] | 423 | For general information, go to the Intel support website at: |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 424 | |
| 425 | http://support.intel.com |
| 426 | |
Jesse Brandeburg | 2115a64 | 2008-07-08 15:51:57 -0700 | [diff] [blame] | 427 | or the Intel Wired Networking project hosted by Sourceforge at: |
| 428 | |
| 429 | http://sourceforge.net/projects/e1000 |
| 430 | |
Linus Torvalds | 1da177e | 2005-04-16 15:20:36 -0700 | [diff] [blame] | 431 | If an issue is identified with the released source code on the supported |
Jesse Brandeburg | 2115a64 | 2008-07-08 15:51:57 -0700 | [diff] [blame] | 432 | kernel with a supported adapter, email the specific information related |
| 433 | to the issue to e1000-devel@lists.sf.net |