Linux Kernel netpoll framework and netconsole

Linux Kernel netpoll framework and netconsole

Although it is related to the network, it is not part of the network protocol stack, Which is netpoll.

It is just a processing framework of the portal. The so-called network, its terminal node is the host, the data is sent from the host's network card, through an exit processing process, the network card receives a packet, through an entry processing process, this inbound process can be handled in two ways:

1. Method of Interruption

Export processing-data is discharged into the sending queue and the specific register value is read. When the NIC status is suitable for sending, send and wait for the notification of interruption after sending to continue.

Entry Processing Process-the process in which the data is received by the NIC, the CPU is interrupted, and the CPU is processed.

The network protocol stack is connected to the interrupt gateway.

2. poll Method

Export processing-data is discharged into the sending queue and read the specific register value. When the NIC status is suitable for sending, it is sent without waiting for the notification of interruption after sending, continue to read the register and determine whether it is suitable for sending Based on the queue situation.

Entry Processing-the data is received by the network adapter, waiting for the poll logic to take the initiative to poll the network adapter when appropriate. If there is data, it will be read from the cache of the specific network adapter.

Linux netpoll is used in this way. This method is completely independent of interruption.

The fact is always more difficult than it is.

To clarify this messy topic, we have to introduce the third method for handling entrances and exits, that is, the combination of interrupt and poll. This is the NAPI method. I will first give the illustration of the three methods:

A. interrupt mode

B. poll Method

C. NAPI Method

After understanding this, the rest will be understood. As for why NAPI exists, this article can only briefly say: in high-speed and high-bandwidth networks, data packets continue to arrive, and if each packet is interrupted once, the CPU will be a little overwhelmed, instead, it delays the CPU processing of these data packets. If the previous data packets have not been processed, the best way is to queue the data packets into a queue, and then silence, do not disturb the CPU, when the CPU is empty, poll the data packets in these queues. This is NAPI.

We are familiar with the method of pure interruption, and it is also the most direct method. But why is there a pure poll approach? When poll is used, the interruption will not work at all. For example, after the system panic. At this time, the interrupt controller may be disable. In any case, the machine has lost connection with the outside world. However, if you need to notify the outside world of the cause of death, this netpoll method comes in handy, because it is manual and completely independent of the system interrupt mechanism. Another scenario is better than panic, that is, protocol stack failure. If we use the interrupt or NAPI method, because it is connected to the protocol stack, there is no HOOK point in netif_receive_skb, in this case, netpoll can be used to change the data packet processing path and remote debug can be implemented through an agent.

Do not think that interruption is too mysterious. It is nothing more than a notification mechanism, telling the CPU, please query my status now, what to do. In fact, when the CPU receives a NIC interruption, it does not know what to do. It only calls the interrupt processing function and reads the status of a write register, then you can know what to do now, such as sending data packets, or receiving a data packet. In this case, the CPU selects the machine to actively call the NIC interrupt processing function to read the status of a write register, even if the disconnection is disabled, can you know what to do? Of course the answer is yes! This is the logic of netpoll. It uses two steps to complete the task:

1. Actively call the interrupt processing function of the network card to obtain whether the sent data packet receives a data packet;

2. directly send the hard_xmit data packet or use the NAPI interface to the data of the poll Nic.

The overall graph of Linux netpoll is as follows:

The figure shows the netconsole principle. I didn't expect it to be so simple. I remember I wrote a module that sent the information after panic to the remote end. This was inspired by an xtables-addons module and failed at first, however, after carefully debugging the kernel code, I succeeded. In the course of success, I found many things that I did not know before. But now let's take a look at netconsole. It does not need anything complicated. It only takes two steps:

1. Register a console, and then the kernel buffer information will be sent to this console;

2. netpoll_send_skb connected to netpoll in the console, which is then processed by the netpoll logic.

Even after the panic, the interruption has been disabled, or even when the interrupt controller is disabled, data can still be sent and received as long as the NIC is not in the water, and it is completely independent of the interruption and protocol stack. This is amazing! About netconsole, I write much better than the kernel Document: $ kernel/Documentation/networking/netconsole.txt.

Netpoll is a tool in the Linux kernel to communicate with the outside world when the protocol stack is unavailable or the interrupt mechanism is abnormal. Of course, netpoll is also a method to bypass the protocol stack. This location is sufficient for the underlying layer, and the written content is certainly more fun than the Netfilter-based one. Netfilter captures data packets at special points in the protocol stack, but netpoll can directly capture data packets on the network card. They cannot even reach the bottom of the protocol stack. In the future, if you want to send packets directly in the kernel state, you no longer need to use PACKET socket to start from the user State. Construct a data PACKET and send it directly through the netpoll interface. The problem is that it uses the method of manually triggering the interrupt processing function and how efficient it is to be tested. Therefore, it is best to limit this mechanism to debugging and sending a small amount of kernel audit information. Using it for VPN, I think it's suspended...

This article permanently updates the link address:

1 2 Next Page