Interrupts and network drivers

Before the kernel is ready to handle frames entering the L2 layer, it is necessary to deal with a sophisticated and complex interrupt system, setting up an interrupt system to process thousands of frames per second.

There are two ways in which network devices communicate with the kernel:

2. Polling: Constantly read a memory register of the device, or when a timer expires, check that memory register to get the device status and whether there are network packets that need to be processed. This approach may seem to waste a lot of system resources than outages, but when interrupts are too frequent, it is a very good way for the system to constantly switch the process context.
4. Interrupt : When a network packet arrives, the device driver indicates that the device is generating a hardware interrupt on behalf of the kernel. The kernel interrupts other activities and then invokes the interrupt-handling routines registered by the device driver, allowing the kernel to process the packets. When a frame is received by the event, the handler queues the frame somewhere, and then notifies the kernel. This is the best option for low-traffic loads, but at high traffic loads the CPU is wasting time switching environments to handle interrupt events.
6. 
   
8. The receiving data frame is divided into two parts.
10. The driver first copies the packet to the input queue that the kernel can access, and then the kernel processes it, usually passing the frame to a handler function dedicated to the relevant protocol. The first part is done in the interrupt environment, can preempt the execution of the second part. Code that accepts and replicates to the receive queue takes precedence over the code that actually processes the frame. Processing of packets may be interrupted by newly arrived data frames.

describes the kernel processing process for receiving and transmitting data frames from a network device

The simplest interrupt mechanism

1. 1. The device generates an interrupt event, the hardware notifies the kernel;
2. 2. If the kernel is not processing other interrupts (or interrupts are not closed for other reasons), the interrupt can be handled;
3. 3. The kernel first shuts down the interrupt function of the local CPU and then executes the interrupt service function of the interrupt event;
4. 4. The kernel leaves the interrupt handler function and then restarts the interrupt function of the local CPU.

Lower half (BH)

2. In short, the interrupt handler function is non-preemptive and cannot be re-entered. This design can help reduce the likelihood of a competitive situation, but the CPU can do a limited amount of things, the kernel does not preempt the design and waiting for the CPU service process, it will have a serious impact on performance. Therefore, the work done by the interrupt handler should be completed as soon as possible. This introduces the upper half (top half) and lower half (Bottom half) of the interrupt handler function. The top half is everything that must be done before the CPU is released, preserving the data, and the bottom half containing everything that can be done comfortably.
4. Linux There are three ways to interrupt the lower half of the process: soft interrupt, Tasklet , Work queue
   
6. 
   

Soft IRQas the representative of the lower half mechanism, the soft interrupt is based on the advent of the SMP (share memory processor), which is also the basis of tasklet implementation (Tasklet actually adds a certain mechanism on the basis of soft interrupts). Soft interrupts are generally a term for "deferred functions" and sometimes include tasklet. It occurs because the difference between the upper and lower halves of the above is met, so that time-insensitive tasks are deferred and can be executed concurrently on multiple CPUs, resulting in a higher overall system efficiency. its features include:

• It does not execute immediately after it is generated, and must wait for the kernel to be dispatched. Soft interrupts cannot be interrupted by themselves and can only be interrupted by hardware interrupts (top half).
• Can run concurrently on multiple CPUs (even if the same type is possible). So a soft interrupt must be designed as a reentrant function (allowing multiple CPUs to operate simultaneously), so a spin lock is required to protect its data structure.

TaskletBecause a soft interrupt must use a reentrant function, this results in a high degree of complexity in design, which adds a burden to the developer as a device driver. If an application does not need to be executed in parallel on multiple CPUs, then a soft interrupt is not necessary. Therefore, Tasklet was born to make up the above two requirements. It has the following characteristics:

• A specific type of tasklet can only be run on one CPU, cannot be parallel, and can only be executed serially.
• Several different types of tasklet can be parallel on multiple CPUs.
• Soft interrupts are statically allocated and cannot be changed after the kernel has been compiled. However, Tasklet is much more flexible and can be changed at runtime (e.g. when adding modules).

Tasklet is implemented on the basis of two types of soft interrupts, so Tasklet is the best choice if the parallel features of soft interrupts are not required. This means that Tasklet is a special use of soft interrupts, i.e. serial execution in the case of delay.
Task Force ColumnAs seen from the above introduction, soft interrupts run in the context of interrupts and therefore cannot be blocked and slept, while Tasklet is implemented using soft interrupts, and of course not blocking and sleeping. But what if a delay handler needs to sleep or block? It's okay. The work queue can be as you wish.
The work queue is another form of deferred work execution. The work queue can be pushed back to a kernel thread to execute-the bottom half is always executed in the process context, but because it is a kernel thread, it cannot access the user space. The most important feature is that the work queue allows rescheduling and even sleep.
In general, it is easy to make choices in the work queue and soft interrupt/tasklet. You can use the following rules:

• If the deferred task requires sleep, then only the work queue can be selected;
• If the deferred task requires a delay time to be triggered again, then the work queue is used because it can take advantage of the timer delay (kernel timer implementation);
• If the deferred task needs to be processed within a tick, a soft interrupt or tasklet is used because it can preempt normal processes and kernel threads while not sleeping;
• If the deferred task does not have any requirements for the delay time, the work queue is used, which is usually a trivial task.

In fact, the essence of a Task Force column is to hand work to kernel threads, so it can be replaced with kernel threads. But the creation and destruction of kernel threads is a high requirement for programmers, and the work queue implements kernel thread encapsulation and is not easy to make mistakes, so we also recommend using the Task Force column.

1. 
   

Interrupts and network drivers