"Copyright notice: Reprint please keep Source: Blog.csdn.net/gentleliu. E-mail: shallnew*163.com "
Before processing the 2-tier packet, the kernel must process the interrupt system, set up an interrupt system, and possibly process thousands of frames per second.
When a frame is received, the driver indicates that the device generates a hardware interrupt on behalf of the kernel, the kernel interrupts other activities, and then invokes a handler that is registered by a driver to meet the needs of the device. When a frame is received by the event, the handler queues the frame somewhere, and then notifies the kernel.
The use of polling technology can easily waste a lot of system resources, because the kernel will continue to read to check if there are frames coming. But using interrupts will force an interrupt every time a frame is received, causing the CPU to waste many hours of processing, and under high traffic loads, the interrupt code will continue to preempt the code being processed, and at some point the input queue will be full, leaving the old frame out of the way, and the new frame cannot be queued. Appears receive-livelock.
The advantage of interruption is that the delay between frame acceptance and its processing is short, and the disadvantage is that it can't run well under high load.
When the CPU receives an interrupt notification message, the handler associated with the interrupt event is called, which is a numbered representation. During the execution of the handler, the kernel is in the interrupt context (interrupt context), and the CPU that serves the interrupt event is shut down, that is, no other interrupt events can be served at this time, and no other processes can be executed, and the CPU is completely part of the interrupt handler and cannot be preempted. In short, the interrupt handler function is non-preemptive and is not re-entered (reentrant). This can reduce the likelihood of a competitive situation, but this has a potentially serious impact on performance.
Therefore, the work of the interrupt handler should be completed as soon as possible, and the interrupt event can preempt the CPU, because if the operating system keeps the hardware too long, the data may be lost, and if the kernel or user space process must be delayed or preempted, no data will be lost. Therefore, the interrupt processing function is now divided into the upper and lower halves. General (1) Tasks are time-sensitive or (2) and task-related or (3) need to be guaranteed not to be interrupted by other interruptions in the upper part of the execution, you can postpone the less urgent task in the lower half of the execution. The lower half is mainly divided into soft interrupts, tasklet, and Task Force columns.
The bottom half of the infrastructure is: 1, the lower part of the class into the appropriate type. 2, the registration of the lower half of the type and the relationship between the processing function. 3, for the lower half of the function scheduling to prepare for execution. 4, notify the kernel has a scheduled BH exists.
The lower half of the kernel (linux-2.6.32) type has: (defined in include/linux/interrupt.h)
enum{ hi_softirq=0, Timer_softirq, Net_tx_softirq, Net_rx_softirq, Block_softirq, BLOCK_IOPOLL_SOFTIRQ, Tasklet_softirq, Sched_softirq, Hrtimer_softirq, RCU_SOFTIRQ,/ * Preferable RCU should always being the last SOFTIRQ */ Nr_softirqs};
A soft IRQ is typically registered within the associated subsystem.
During kernel initialization, Softirq_init registers the handler functions associated with TASKLET_SOFTIRQ and HI_SOFTIRQ.
void __init softirq_init (void) { ... OPEN_SOFTIRQ (TASKLET_SOFTIRQ, tasklet_action); OPEN_SOFTIRQ (HI_SOFTIRQ, tasklet_hi_action);}
The network subsystem is divided into two kinds of soft IRQ. NET_TX_SOFTIRQ and NET_RX_SOFTIRQ, respectively, handle sending packets and receiving packets. These two soft IRQ are registered in the Net_dev_init function (NET/CORE/DEV.C):
OPEN_SOFTIRQ (NET_TX_SOFTIRQ, net_tx_action); OPEN_SOFTIRQ (NET_RX_SOFTIRQ, net_rx_action);
The soft interrupt handler functions for sending and receiving packets are registered as Net_rx_action and net_tx_action.
Where OPEN_SOFTIRQ is implemented as:
void Open_softirq (int nr, void (*action) (struct softirq_action *)) { softirq_vec[nr].action = action;}
