=下面列出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.

總結

以上是生活随笔為你收集整理的linux修改端口cost值,Linux下通过修改网卡驱动的参数调整Intel网卡的性能的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。