Linux下通过修改网卡驱动的参数调整Intel网卡的性能zz

命令行参数

使用下列选项参数的方法是将其以 modprobe 或 insmod 命令输入至命令行中，使用的语法如下：

modprobe e1000 [<选项>=<VAL1>,<VAL2>,...]

insmod e1000 [<选项>=<VAL1>,<VAL2>,...]

有关参数和可能的值，请参考以下表格。

例如，有两个英特尔 PRO/1000 PCI 适配器时，输入：

insmod e1000 TxDescriptors=80,128

为第一个适配器加载具有 80TX 的 e1000 驱动程序，为第二个适配器加载具有 128 TX 资源的 e1000 驱动程序。

各个参数的默认值通常就是推荐使用的设置（另行说明的除外）。

欲获得关于 AutoNeg、Duplex 和 Speed 参数的更多信息，参阅本文档中速度和双工配置节。

以下表格包含用于 insmod 和 modprobe 命令的参数和可能的值：

参数名	有效范围／设置	默认	描述
AutoNeg （参见以下 表格 以了解各值）	0x01-0x0F, 0x20-0x2F	0x2F	该参数是一个位屏蔽，指定网卡所广告的速度和双工设置。 使用该参数时，不得指定 Speed 和 Duplex 参数。 （仅适用于使用铜触点的适配器）
Duplex	0-2 (0=自动协商，1=半，2=全）	0	定义数据允许的流向。 可为单向或双向。 如果 Duplex 与链接伙伴均设为自动协商，则网卡将自动测试正确的双工模式。 如果链接伙伴强制设置（全双工或者半双工），Duplex 默认设置为半双工。 （仅适用于使用铜触点的适配器）
FlowControl	0-3（0=无，1=仅 Rx，2=仅 Tx，3=Rx 和 Tx）	从 EEPROM 读入流量控制设置	此参数控制对以太网 PAUSE 帧的自动生成（Tx）和响应（Rx）。
InterruptThrottleRate	100-100000 (0=关)	8000	此值代表控制器每秒种生成的最大的中断数量。 InterruptThrottleRate 是用于中断调节的另一个设置。 动态模式使用试探式算法根据当前通信来负载调整 InterruptThrottleRate。 注 意： InterruptThrottleRate 优先于 TxAbsIntDelay 和 RxAbsIntDelay 参数。 换句话说，缩短接收和/或传输的绝对延迟不会强制控制器生成大于 Interrupt Throttle Rate（中断节流率）允许的中断量。
RxDescriptors	基于 82542 和 82544 的适配器为 80-256 基于 82540，82544，82545 和 82546 的适配器为 80-4096	80	此 数值是驱动程序所分配的接收描述符的数量。 增大此数值将允许驱动程序把更多的进入包放入缓冲区。 每一描述符为 16 字节。 每个描述符还配有一个接收缓冲区，按 MTU 的设置，其大小可为 2048、4096、8192 或 16384 字节。 MTU 最大值为 is 16110。 注意： MTU 指定帧幅大小。 仅需为巨帧设置。
RxIntDelay	0-65535 (0=关)	0	该 值以 1.024 微秒为单位延迟接收中断的生成。 如果针对特定的网络交通量调整，减少接收中断可提高 CPU 效率。 增大该值会为帧接收添加额外的等待时间，可能导致 TCP 交通吞吐量降低。 如果系统报告接收信息包被丢弃，该值可能设置得太高，导致驱动程序用尽了可用的接收描述符。 注 意： 在某种网络情况下，将 RxIntDelay 设置为 0 以外的值会导致挂起（停止传输）。 如发生此情况，会在系统事件日志中记入一条 NETDEV WATCHDOG 消息。 此外，控制器会自动重置，恢复网络连接。 要避免发生挂起，确保将 RxIntDelay 设为零。
RxAbsIntDelay	0-65535 (0=关)	128	此值以 1.024 微秒为单位，它限制生成接收中断的延迟。 此值仅在 RxIntDelay 为非零时才有用。它确保初始数据包在一定时间内被接收后便生成一个中断 。 恰当的微调，加上 RxIntDelay，将可能在特定的网络状态下提高通信吞吐量。 （仅适用于 82540、82545和基于 82546 的适配器)
Speed	0, 10, 100, 1000	0	Speed 强制线速度为指定的值，以每秒千兆位（Mbps）为单位。 如果该参数没有指定或设置为 0，而链接伙伴设为自动协商，则网卡将自动检测正确的速度。 但速度被设置为 10 或100 时，必须也设置双工模式。 （仅适用于使用铜触点的适配器）
TxDescriptors	基于 82542 和 82544 的适配器为 80-256 基于 82540，82544，82545 和 82546 的适配器为 80-4096	256	此数值是驱动程序所分配的传输描述符的数量。 增大此数值将允许驱动程序把更多的传输包排入队列。 每一描述符为 16 字节。
TxIntDelay	0-65535 (0=关)	64	该值以 1.024 微秒为单位延迟传输中断的生成。 如果针对特定的网络交通量调整，减少传输中断可提高 CPU 效率。 如果系统报告传输信息包被丢弃，该值可能设置得太高，导致驱动程序用尽了可用的传输描述符。
TxAbsIntDelay	0-65535 (0=关)	64	此值以 1.024 微秒为单位，它限制生成传输中断的延迟。 此值仅在 TxIntDelay 为非零时才有用。它确保初始数据包在一定时间内被通过线路传输以后便生成一个中断 。 恰当的微调，加上 TxIntDelay，将可能在特定的网络状态下提高通信吞吐量。 （仅适用于 82540、82545和基于 82546 的适配器)
XsumRX	0-1	1	数值'1'表示驱动程序应为接收的信息包（UDP 和 TCP 二者) 启用 IP 校验和分载至适配器硬件。

返回页首

---

速度和双工配置

速度和双工配置用三个关键字来控制。 这三个关键字是 Speed（速度）、Duplex（双工）和 AutoNeg（自动协商）。

如果网卡使用光纤接口，这些关键字将被忽略，光纤接口网卡仅以 1000 Mbps 全双工链接。

对铜质网卡，关键字互相配合如下：

默认操作为自动协商。 网卡广告所有支持的速度和双工组合，并且如果链接伙伴设为自动协商，它将以最快的共同速度和双工模式进行链接。

如果 Speed = 1000，仅启用有限的自动协商，且只广告 1000 Mbps（1000BaseT 规格要求自动协商）。

如果 Speed = 10 或 100，那么 Speed 和 Duplex 都必须设置。 自动协商被禁用，AutoNeg 参数被忽略。 链接伙伴也必须强制设置。

如果要求对自动协商进程有更多的控制，使用 AutoNeg 参数。 使用该参数时，不得指定 Speed 和 Duplex。 该参数是指定向连接伙伴广告何种速度和双工设置的位映像。

位:	7	6	5	4	3	2	1	0
Speed（Mbps）：	不适用	不适用	1000	不适用	100	100	10	10
Duplex（双工模式）：			全		全	半	全	半

注意：AutoNeg 设置不保证网卡以指定的最高速度或双工模式链接，但是，如果链接伙伴也设成自动协商，网卡将以链接伙伴可能达到的最高速度/双工进行链接。 如果链接伙伴被强制设置速度/双工，那么适配器必须被强制设置成相同的速度/双工。

Reference:

A Sample Configuration

Some example settings are described below. These numbers are for illustration purposes only. For

optimal performance, the exact controller configuration is best determined through actual

experimentation.

The discussion below assumes that software is optimizing for full-size frames of 1538 bytes.

The calculations below make use of the following facts:

•Gigabit Ethernet operates at 1.0 Gb/s or 1,000,000,000 bits per second. At this speed, the time required to transmit or receive a single bit (in other words, the bit-time) is 1.0 nanosecond.

•A full-size Ethernet frame requires 1538 bytes (12,304 bits) of bandwidth:

—8-byte preamble and start-of-frame delimiter

—14-byte Ethernet header

—1500-byte payload

—4-byte FCS

—12-byte inter-packet gap

•The controller can transmit or receive a full-size frame every 12.3 microseconds or approximately 81,000 packets per second.

Absolute Timers

Configuring the absolute timers is typically a matter of determining the desired interrupt rate or the

desired number of packets per interrupt. To receive approximately 3000 interrupts per second,software would configure the absolute timers to interrupt every 333 microseconds.

Alternately, to receive approximately 50 packets per interrupt, the controller must interruptapproximately 1620 times per second (81,000 packets-per-second at 50 packets-per-interrupt).

Software would then configure the absolute timers to interrupt every 617 microseconds.

Packet Timers

Experiments have shown that values between 20 and 40 microseconds work well for the packettimers.

Software might set the packet timers to expire after 2 full-length packet-times, or approximately 25

microseconds. The packet timers would then expire when throughput falls below about 333Mbps

(two unused packet-times follow every packet arrival, so approximately one-third of the total

bandwidth is in use). At greater levels of utilization, the packet timers would likely chain

repeatedly until the one of the absolute timers expired.

Interrupt Throttle Timer

Configuring the throttle timer is simply a question of determining the desired maximum interrupt

rate. As described earlier, software may realize better results by setting the throttle timer to

interrupt slightly more often than desired to reduce unnecessary latencies.

For typical applications, software might configure the controller to interrupt no more than 5000

times per second.

Different operating systems and environments will be capable of sustaining different maximum

interrupt rates. Experiments have demonstrated that Microsoft Windows-based operating systems

perform best when the device interrupts between 4,000 and 12,000 times per second. Linux-based

operating systems appear to perform best with an interrupt rate between 1,000 and 8,000 interrupts

per second. Other operating systems will perform differently.

Additional Tuning Considerations

The example configuration described above will require modifications to suit the intended

environment. The following factors may influence the tuning of the interrupt moderationparameters:

•The latency associated with scheduling an interrupt handler. Larger scheduling latencies

 imply larger packet latencies. Lower interrupt delays may be required in these situations

to avoid overrun conditions and excessive per-packet delays.

•The cost associated with handling an interrupt. In OS with low-cost interrupts, higher interrupt rates may be acceptable. In OS with high-cost interrupts, lower interrupt rates may be required.

•The expected mixture of packet sizes. The preceding discussion assumes that software is optimizing for full-size frames. Optimizing for small packets or for a variety of packet sizes requires recalculating the expected packet rate.

•The expected network utilization. High utilization implies high traffic rates, which makes the controller more susceptible to overrun conditions if it delays interrupts too long.