Andi Kleen wrote:
On Thursday 02 February 2006 08:31, Greg Banks wrote:
The tg3 driver uses small hardcoded values for the RXCOL_TICKS
and RXMAX_FRAMES registers, and allows "ethtool -C" to change
them. SGI's solution is do is ship a script that uses ethtool
at boot to tune rx-usecs, rx-frames, rx-usecs-irq, rx-frames-irq
up from the defaults.
All user tuning like this is bad. The stack should all do that automatically.
Would there be a drawback of making these
settings default?
Larger settings (even the defaults) of the coalescing parms, while giving decent
CPU utilization for a bulk transfer and better CPU utilization for a large
agregate workload seem to mean bad things for minimizing latency.
The "presentation" needs work but the data in:
ftp://ftp.cup.hp.com/dist/networking/briefs/nic_latency_vs_tput.txt
should show some of that. The current executive summary:
Executive Summary:
By default, the e1000 driver used in conjunction with the A9900A PCI-X
Dual-port Gigabit Ethernet adaptor strongly favors maximum packet per
second throughput over minimum request/response latency. Anyone
desiring lowest possible request/response latency needs to alter the
modprobe parameters used when the e1000 driver is loaded. This
appears to reduce round-trip latency by as much as 85%.
However, configuring the A9900A PCI-X Dual-port Gigabit Ethernet
adaptor for minimum request/response latency will reduce maximum
packet per second performance (as measured with the netperf TCP_RR
test) by ~23% and increase the service demand for bulk data transfer
by ~63% for sending and ~145% for receiving.
there is also some data in there for tg3 and for xframe I (but with a rather
behind the times driver, i'm still trying to get cycles to run with a newer driver)
This helps a lot, and we're very grateful ;-) But a scheme
which used the interrupt mitigation hardware dynamically based on
load could reduce the irq rate and CPU usage even further without
compromising latency at low load.
If you know what's needed perhaps you could investigate it?
I'm guessing that any automagic interrupt mitigation scheme might want to know
what it wants to enable for the single-stream TCP_RR transaction/s as the base
pps before it starts holding-off interrupts. Even then however, the ability for
the user to overrride needs to remain because there may be a workload that wants
that PPS rate, but isn't concerned about the latency, only the CPU utilization
and so indeed wants the interrupts mitigated. So it would seem that an
automagic coalescing might be an N% solution, but I don't think it would be
100%. Question then becomes whether or not N is large enough to warrant it over
defaults+manual config.
rick jones
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
