命令行参数
使用下列选项参数的方法是将其以 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。
| ||
RxDescriptors | 基于 82542 和 82544 的适配器为 80-256 基于 82540,82544,82545 和 82546 的适配器为 80-4096 | 80 | 此 数值是驱动程序所分配的接收描述符的数量。 增大此数值将允许驱动程序把更多的进入包放入缓冲区。 每一描述符为 16 字节。 每个描述符还配有一个接收缓冲区,按 MTU 的设置,其大小可为 2048、4096、8192 或 16384 字节。 MTU 最大值为 is 16110。
| ||
RxIntDelay | 0-65535 (0=关) | 0 | 该 值以 1.024 微秒为单位延迟接收中断的生成。 如果针对特定的网络交通量调整,减少接收中断可提高 CPU 效率。 增大该值会为帧接收添加额外的等待时间,可能导致 TCP 交通吞吐量降低。 如果系统报告接收信息包被丢弃,该值可能设置得太高,导致驱动程序用尽了可用的接收描述符。
| ||
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.