On Thu, 24 Aug 2000, Marcell Gal wrote:
> Is there any way (for some ethernet drivers at least) to delay
> interrupts (eg. with x00 us), so that many packets are serviced in
> one go instead of many proc-time-eating interrupts?
Sure, and drivers already do this.
> Alan Kennington suggested (to me) that there was a way to do this
> without
> HW support: in case of higher traffic we disable normal interrupts
> and do service when timer-expires (this might require raising HZ above
> 100). (if no frames are coming, or less than a treshold, we can
> reenable interrupts).
If you work through the problem, doing this purely in software is
complicated and might not be worth the extra complexity for general purpose
systems. If you have such a overwhelming load, just buy hardware with
hardware interrupt mitigation.
Many drivers do transmit interrupt mitigation in software: they don't raise
an interrupt for each Tx-done event. This might result in out-of-sync Tx
statistics, but in normal use you usually get a receive interrupt soon after
transmitting a packet. (Note: this is not true when you need accurate
statistics the most: when you are tracking down network problems.)
Doing software receive interrupt mitigation results in very high latency.
This is especially bad for protocols with short packet ping-pong
communication, and biases network access to large packet, large window
communication.
The "hot ticket" in Ethernet designs used to be exactly the opposite
approach: predictive Rx interrupts. The hardware raised an interrupt
before the packet had completely arrived. You might take two interrupts per
packet, but the resulting performance for certain protocols and environments
won benchmarks.
> Alan says the Nicstar ATM card has HW support for [369]00 us INT delay.
> Any ethernet cards known to have similar smart features?
The 21143 is a common, low-cost example.
All gigabit Ethernet boards have some sort of mitigation.
> Is anything like this configurable for some ethernet drivers, has
> anyone done some successful or unsuccessful experiments with this?
See the work by Josip Loncaric in the Tulip mailing list achieve for a
write-up on the 21143 mitigation.
I've also done experiments, but the result have usually gone directly into
the drivers. I've learned that writing up the results is usually wasted
time: A few years ago I did profiles of the typical transmit queue length
and packet dwell period. I wrote up the results, complete with charts and
graphs and Xs and Os on the back, but no one on the driver mailing lists was
interested. It's pretty mundane topic, and wouldn't make a substantial
conference paper. So now I just use the final numbers.
Donald Becker becker@xxxxxxxxx
Scyld Computing Corporation http://www.scyld.com
410 Severn Ave. Suite 210 Beowulf-II Cluster Distribution
Annapolis MD 21403
|