Interrupt Processing

Introduction

When an end system NIC receives a packet it will raise an interrupt. This might be done immediately, or it might be delayed, depending on how the NIC is configured. A good example of a time when an immediate interrupt is configured is in the case of One Way Delay measurement - in order to get the most accurate value for the OWD of the network path it is important that newly arrived OWD probes are timestamped as soon as possible, and if the timestamping is done by the host CPU (as in HADES case) then the packet must be sent to the CPU as soon as possible. However, if a large number of packets arrive consecutively (as in the case of a high data rate application), it would be counter-productive to generate an interrupt for each individual packet. Rather, the most efficient way to process the traffic would be to raise an interrupt once the NIC's buffer is nearly full (not actually full, as there is the risk that in the time it takes to service the interrupt another packet might arrive and have to be dropped due to lack of space).

Shared Interrupts

Many systems have more IO devices than they have usable interrupts, which means that IO devices often have to share interrupt numbers. It appears not much thought is given to which devices share interrupts, with the result that sometimes parallel and serial ports will have their own dedicated interrupts whilst other devices, including high-speed NICs, have to share an interrupt.

-- TobyRodwell - 25 Jan 2007

Edit | Attach | Watch | Print version | History: r2 < r1 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r2 - 2007-01-25 - TobyRodwell
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2004-2009 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.