353 lines
14 KiB
Plaintext
353 lines
14 KiB
Plaintext
|
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.
|
||
|
|
|
||
|
|
===============================================================================
|