Linux下通过修改网卡驱动的参数调整Intel网卡的性能
|
Intel的千兆网卡驱动(e1000.ko)加载的时候可以加上几个参数，如下：
insmod e1000.ko <parameter>=<value>
下面列出paramerter中和性能相关的几个以及他们的取值范围和默认值。
InterruptThrottleRate
范围：100-100000 (0=off, 1=dynamic)
默认：0
注：不支持82542, 82543, 82545, 82544芯片
RxDescriptors
范围：80-256 for 82542 and 82543-based adapters
80-4096 for all other supported adapters
默认:256
RxIntDelay
范围：0-65535 (0=off)
默认：0
RxAbsIntDelay
范围：0-65535 (0=off)
默认：128
TxDescriptors
范围：80-256 for 82542 and 82543-based adapters
80-4096 for all other supported adapters
默认：256
TxIntDelay
范围：0-65535 (0=off)
默认：64
TxAbsIntDelay
范围：0-65535 (0=off)
默认：64
其中各种*IntDelay的单位是：1.024 microseconds
我们可以根据网卡的性能和cpu，内存，pci总线等不同来调整它们的值，另外可以编译网卡驱动的时候修改编译选项：NAPI和NO_NAPI。
make CFLAGS_EXTRA=-DCONFIG_E1000_NAPI
我找到一个关于如何修改这些参数取值得例子不过是英文的，怕翻译的不好，还是放上来原文吧。
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. |