| Chelsio N210 10Gb Ethernet Network Controller |
| |
| Driver Release Notes for Linux |
| |
| Version 2.1.1 |
| |
| June 20, 2005 |
| |
| CONTENTS |
| ======== |
| INTRODUCTION |
| FEATURES |
| PERFORMANCE |
| DRIVER MESSAGES |
| KNOWN ISSUES |
| SUPPORT |
| |
| |
| INTRODUCTION |
| ============ |
| |
| This document describes the Linux driver for Chelsio 10Gb Ethernet Network |
| Controller. This driver supports the Chelsio N210 NIC and is backward |
| compatible with the Chelsio N110 model 10Gb NICs. |
| |
| |
| FEATURES |
| ======== |
| |
| Adaptive Interrupts (adaptive-rx) |
| --------------------------------- |
| |
| This feature provides an adaptive algorithm that adjusts the interrupt |
| coalescing parameters, allowing the driver to dynamically adapt the latency |
| settings to achieve the highest performance during various types of network |
| load. |
| |
| The interface used to control this feature is ethtool. Please see the |
| ethtool manpage for additional usage information. |
| |
| By default, adaptive-rx is disabled. |
| To enable adaptive-rx: |
| |
| ethtool -C <interface> adaptive-rx on |
| |
| To disable adaptive-rx, use ethtool: |
| |
| ethtool -C <interface> adaptive-rx off |
| |
| After disabling adaptive-rx, the timer latency value will be set to 50us. |
| You may set the timer latency after disabling adaptive-rx: |
| |
| ethtool -C <interface> rx-usecs <microseconds> |
| |
| An example to set the timer latency value to 100us on eth0: |
| |
| ethtool -C eth0 rx-usecs 100 |
| |
| You may also provide a timer latency value while disabling adaptive-rx: |
| |
| ethtool -C <interface> adaptive-rx off rx-usecs <microseconds> |
| |
| If adaptive-rx is disabled and a timer latency value is specified, the timer |
| will be set to the specified value until changed by the user or until |
| adaptive-rx is enabled. |
| |
| To view the status of the adaptive-rx and timer latency values: |
| |
| ethtool -c <interface> |
| |
| |
| TCP Segmentation Offloading (TSO) Support |
| ----------------------------------------- |
| |
| This feature, also known as "large send", enables a system's protocol stack |
| to offload portions of outbound TCP processing to a network interface card |
| thereby reducing system CPU utilization and enhancing performance. |
| |
| The interface used to control this feature is ethtool version 1.8 or higher. |
| Please see the ethtool manpage for additional usage information. |
| |
| By default, TSO is enabled. |
| To disable TSO: |
| |
| ethtool -K <interface> tso off |
| |
| To enable TSO: |
| |
| ethtool -K <interface> tso on |
| |
| To view the status of TSO: |
| |
| ethtool -k <interface> |
| |
| |
| PERFORMANCE |
| =========== |
| |
| The following information is provided as an example of how to change system |
| parameters for "performance tuning" an what value to use. You may or may not |
| want to change these system parameters, depending on your server/workstation |
| application. Doing so is not warranted in any way by Chelsio Communications, |
| and is done at "YOUR OWN RISK". Chelsio will not be held responsible for loss |
| of data or damage to equipment. |
| |
| Your distribution may have a different way of doing things, or you may prefer |
| a different method. These commands are shown only to provide an example of |
| what to do and are by no means definitive. |
| |
| Making any of the following system changes will only last until you reboot |
| your system. You may want to write a script that runs at boot-up which |
| includes the optimal settings for your system. |
| |
| Setting PCI Latency Timer: |
| setpci -d 1425:* 0x0c.l=0x0000F800 |
| |
| Disabling TCP timestamp: |
| sysctl -w net.ipv4.tcp_timestamps=0 |
| |
| Disabling SACK: |
| sysctl -w net.ipv4.tcp_sack=0 |
| |
| Setting large number of incoming connection requests: |
| sysctl -w net.ipv4.tcp_max_syn_backlog=3000 |
| |
| Setting maximum receive socket buffer size: |
| sysctl -w net.core.rmem_max=1024000 |
| |
| Setting maximum send socket buffer size: |
| sysctl -w net.core.wmem_max=1024000 |
| |
| Set smp_affinity (on a multiprocessor system) to a single CPU: |
| echo 1 > /proc/irq/<interrupt_number>/smp_affinity |
| |
| Setting default receive socket buffer size: |
| sysctl -w net.core.rmem_default=524287 |
| |
| Setting default send socket buffer size: |
| sysctl -w net.core.wmem_default=524287 |
| |
| Setting maximum option memory buffers: |
| sysctl -w net.core.optmem_max=524287 |
| |
| Setting maximum backlog (# of unprocessed packets before kernel drops): |
| sysctl -w net.core.netdev_max_backlog=300000 |
| |
| Setting TCP read buffers (min/default/max): |
| sysctl -w net.ipv4.tcp_rmem="10000000 10000000 10000000" |
| |
| Setting TCP write buffers (min/pressure/max): |
| sysctl -w net.ipv4.tcp_wmem="10000000 10000000 10000000" |
| |
| Setting TCP buffer space (min/pressure/max): |
| sysctl -w net.ipv4.tcp_mem="10000000 10000000 10000000" |
| |
| TCP window size for single connections: |
| The receive buffer (RX_WINDOW) size must be at least as large as the |
| Bandwidth-Delay Product of the communication link between the sender and |
| receiver. Due to the variations of RTT, you may want to increase the buffer |
| size up to 2 times the Bandwidth-Delay Product. Reference page 289 of |
| "TCP/IP Illustrated, Volume 1, The Protocols" by W. Richard Stevens. |
| At 10Gb speeds, use the following formula: |
| RX_WINDOW >= 1.25MBytes * RTT(in milliseconds) |
| Example for RTT with 100us: RX_WINDOW = (1,250,000 * 0.1) = 125,000 |
| RX_WINDOW sizes of 256KB - 512KB should be sufficient. |
| Setting the min, max, and default receive buffer (RX_WINDOW) size: |
| sysctl -w net.ipv4.tcp_rmem="<min> <default> <max>" |
| |
| TCP window size for multiple connections: |
| The receive buffer (RX_WINDOW) size may be calculated the same as single |
| connections, but should be divided by the number of connections. The |
| smaller window prevents congestion and facilitates better pacing, |
| especially if/when MAC level flow control does not work well or when it is |
| not supported on the machine. Experimentation may be necessary to attain |
| the correct value. This method is provided as a starting point for the |
| correct receive buffer size. |
| Setting the min, max, and default receive buffer (RX_WINDOW) size is |
| performed in the same manner as single connection. |
| |
| |
| DRIVER MESSAGES |
| =============== |
| |
| The following messages are the most common messages logged by syslog. These |
| may be found in /var/log/messages. |
| |
| Driver up: |
| Chelsio Network Driver - version 2.1.1 |
| |
| NIC detected: |
| eth#: Chelsio N210 1x10GBaseX NIC (rev #), PCIX 133MHz/64-bit |
| |
| Link up: |
| eth#: link is up at 10 Gbps, full duplex |
| |
| Link down: |
| eth#: link is down |
| |
| |
| KNOWN ISSUES |
| ============ |
| |
| These issues have been identified during testing. The following information |
| is provided as a workaround to the problem. In some cases, this problem is |
| inherent to Linux or to a particular Linux Distribution and/or hardware |
| platform. |
| |
| 1. Large number of TCP retransmits on a multiprocessor (SMP) system. |
| |
| On a system with multiple CPUs, the interrupt (IRQ) for the network |
| controller may be bound to more than one CPU. This will cause TCP |
| retransmits if the packet data were to be split across different CPUs |
| and re-assembled in a different order than expected. |
| |
| To eliminate the TCP retransmits, set smp_affinity on the particular |
| interrupt to a single CPU. You can locate the interrupt (IRQ) used on |
| the N110/N210 by using ifconfig: |
| ifconfig <dev_name> | grep Interrupt |
| Set the smp_affinity to a single CPU: |
| echo 1 > /proc/irq/<interrupt_number>/smp_affinity |
| |
| It is highly suggested that you do not run the irqbalance daemon on your |
| system, as this will change any smp_affinity setting you have applied. |
| The irqbalance daemon runs on a 10 second interval and binds interrupts |
| to the least loaded CPU determined by the daemon. To disable this daemon: |
| chkconfig --level 2345 irqbalance off |
| |
| By default, some Linux distributions enable the kernel feature, |
| irqbalance, which performs the same function as the daemon. To disable |
| this feature, add the following line to your bootloader: |
| noirqbalance |
| |
| Example using the Grub bootloader: |
| title Red Hat Enterprise Linux AS (2.4.21-27.ELsmp) |
| root (hd0,0) |
| kernel /vmlinuz-2.4.21-27.ELsmp ro root=/dev/hda3 noirqbalance |
| initrd /initrd-2.4.21-27.ELsmp.img |
| |
| 2. After running insmod, the driver is loaded and the incorrect network |
| interface is brought up without running ifup. |
| |
| When using 2.4.x kernels, including RHEL kernels, the Linux kernel |
| invokes a script named "hotplug". This script is primarily used to |
| automatically bring up USB devices when they are plugged in, however, |
| the script also attempts to automatically bring up a network interface |
| after loading the kernel module. The hotplug script does this by scanning |
| the ifcfg-eth# config files in /etc/sysconfig/network-scripts, looking |
| for HWADDR=<mac_address>. |
| |
| If the hotplug script does not find the HWADDRR within any of the |
| ifcfg-eth# files, it will bring up the device with the next available |
| interface name. If this interface is already configured for a different |
| network card, your new interface will have incorrect IP address and |
| network settings. |
| |
| To solve this issue, you can add the HWADDR=<mac_address> key to the |
| interface config file of your network controller. |
| |
| To disable this "hotplug" feature, you may add the driver (module name) |
| to the "blacklist" file located in /etc/hotplug. It has been noted that |
| this does not work for network devices because the net.agent script |
| does not use the blacklist file. Simply remove, or rename, the net.agent |
| script located in /etc/hotplug to disable this feature. |
| |
| 3. Transport Protocol (TP) hangs when running heavy multi-connection traffic |
| on an AMD Opteron system with HyperTransport PCI-X Tunnel chipset. |
| |
| If your AMD Opteron system uses the AMD-8131 HyperTransport PCI-X Tunnel |
| chipset, you may experience the "133-Mhz Mode Split Completion Data |
| Corruption" bug identified by AMD while using a 133Mhz PCI-X card on the |
| bus PCI-X bus. |
| |
| AMD states, "Under highly specific conditions, the AMD-8131 PCI-X Tunnel |
| can provide stale data via split completion cycles to a PCI-X card that |
| is operating at 133 Mhz", causing data corruption. |
| |
| AMD's provides three workarounds for this problem, however, Chelsio |
| recommends the first option for best performance with this bug: |
| |
| For 133Mhz secondary bus operation, limit the transaction length and |
| the number of outstanding transactions, via BIOS configuration |
| programming of the PCI-X card, to the following: |
| |
| Data Length (bytes): 1k |
| Total allowed outstanding transactions: 2 |
| |
| Please refer to AMD 8131-HT/PCI-X Errata 26310 Rev 3.08 August 2004, |
| section 56, "133-MHz Mode Split Completion Data Corruption" for more |
| details with this bug and workarounds suggested by AMD. |
| |
| It may be possible to work outside AMD's recommended PCI-X settings, try |
| increasing the Data Length to 2k bytes for increased performance. If you |
| have issues with these settings, please revert to the "safe" settings |
| and duplicate the problem before submitting a bug or asking for support. |
| |
| NOTE: The default setting on most systems is 8 outstanding transactions |
| and 2k bytes data length. |
| |
| 4. On multiprocessor systems, it has been noted that an application which |
| is handling 10Gb networking can switch between CPUs causing degraded |
| and/or unstable performance. |
| |
| If running on an SMP system and taking performance measurements, it |
| is suggested you either run the latest netperf-2.4.0+ or use a binding |
| tool such as Tim Hockin's procstate utilities (runon) |
| <http://www.hockin.org/~thockin/procstate/>. |
| |
| Binding netserver and netperf (or other applications) to particular |
| CPUs will have a significant difference in performance measurements. |
| You may need to experiment which CPU to bind the application to in |
| order to achieve the best performance for your system. |
| |
| If you are developing an application designed for 10Gb networking, |
| please keep in mind you may want to look at kernel functions |
| sched_setaffinity & sched_getaffinity to bind your application. |
| |
| If you are just running user-space applications such as ftp, telnet, |
| etc., you may want to try the runon tool provided by Tim Hockin's |
| procstate utility. You could also try binding the interface to a |
| particular CPU: runon 0 ifup eth0 |
| |
| |
| SUPPORT |
| ======= |
| |
| If you have problems with the software or hardware, please contact our |
| customer support team via email at support@chelsio.com or check our website |
| at http://www.chelsio.com |
| |
| =============================================================================== |
| |
| Chelsio Communications |
| 370 San Aleso Ave. |
| Suite 100 |
| Sunnyvale, CA 94085 |
| http://www.chelsio.com |
| |
| This program is free software; you can redistribute it and/or modify |
| it under the terms of the GNU General Public License, version 2, as |
| published by the Free Software Foundation. |
| |
| You should have received a copy of the GNU General Public License along |
| with this program; if not, write to the Free Software Foundation, Inc., |
| 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. |
| |
| THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR IMPLIED |
| WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF |
| MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. |
| |
| Copyright (c) 2003-2005 Chelsio Communications. All rights reserved. |
| |
| =============================================================================== |