Chapter 10. Frame Reception--深入理解linux网络技术内幕--嵌入式linux中文站

In the previous chapter, we saw that the functions that deal with frames at the L2 layer are driven by interrupts. In this chapter, we start our discussion about frame reception, where the hardware uses an interrupt to signal the CPU about the availability of the frame.

As shown in Figure 9-2 in Chapter 9, the CPU that receives an interrupt executes the do_IRQ function. The IRQ number causes the right handler to be invoked. The handler is typically a function within the device driver registered at device driver initialization time. IRQ function handlers are executed in interrupt mode, with further interrupts temporarily disabled.

As discussed in the section "Interrupt Handlers" in Chapter 9, the interrupt handler performs a few immediate tasks and schedules others in a bottom half to be executed later. Specifically, the interrupt handler:

Copies the frame into an sk_buff data structure.^[*]
^[*] If DMA is used by the device, as is pretty common nowadays, the driver needs only to initialize a pointer (no copying is involved).
Initializes some of the sk_buff parameters for use later by upper network layers (notably skb->protocol, which identifies the higher-layer protocol handler and will play a major role in Chapter 13).
Updates some other parameters private to the device, which we do not consider in this chapter because they do not influence the frame's path inside the network stack.
Signals the kernel about the new frame by scheduling the NET_RX_SOFTIRQ softirq for execution.

Since a device can issue an interrupt for different reasons (new frame received, frame transmission successfully completed, etc.), the kernel is given a code along with the interrupt notification so that the device driver handler can process the interrupt based on the type.