它只是一个出入口的处理框架。所谓的网络，它的终端节点就是主机，数据从主机的网卡发出，经过一个出口处理过程，网卡接收到一个数据包，经过一个入口处理过程，这一出一入的过程处理分为两种方式：
1.中断的方式
出口处理过程-数据排入发送队列，读取特定寄存器值，待网卡状态适合发送式，发送，等待发送后的中断通知，继续。
入口处理过程-数据被网卡收到，网卡中断CPU，CPU进而处理数据接收的过程。
网络协议栈下接的就是这种中断的出入口处理方式。
2.poll的方式
出口处理过程-数据排入发送队列，读取特定寄存器值，待网卡状态适合发送式，发送，不等待发送后的中断通知，继续读取寄存器以及根据队列情况权衡是否适合发送。
入口处理过程-数据被网卡收到，等待poll逻辑在适当的时候去主动poll网卡，若有数据，则将其从特定的网卡缓存读出。
Linux netpoll就是利用的这种方式。这种方式完全不依赖中断。
事实总是比说起来更麻烦。
要讲清楚这个有点混乱的主题，不得不引入第三种出入口处理方式，那就是中断和poll结合的方式，这就是NAPI方式。我把三种方式的图示先给出：
a.中断方式
b.poll方式
c.NAPI方式
理解了这个，剩下的就都理解了。至于为何会有NAPI，在本文中只能简单说一句：在高速高带宽网络中，数据包持续到来，每一个包中断一次CPU的话，CPU有点吃不消，反而耽误了CPU处理这些数据包，如果之前的数据包还没有处理完，最好的办法就是将数据包排入一个队列，然后沉默，不要打扰CPU，等CPU空下来的时候，自己去poll这些队列里面的数据包，这就是NAPI。
纯中断的方式我们都很熟悉，也是最直接的方式。然而为何要有纯poll的方式呢？使用纯poll的场合在中断完全不起作用的情况下。举一个例子，系统panic之后。此时中断控制器将可能被disable掉，无论如何，此时的机器已经和外界失联了，然而如果此时必须需要一个方式对外界通告自己的死因的话，这种netpoll的方式就派上用场了，因为它是纯手工的，完全不依赖系统的中断机制。另外一种场合比panic好一些，那就是协议栈故障，如果使用中断或者NAPI的方式，由于它上接的就是协议栈，netif_receive_skb中又没有什么HOOK点，此时使用netpoll可以改变数据包的处理路径，通过一个agent可以实现远程debug。
不要把中断想象的太神秘。它无非也就是一个通知机制，告诉CPU，现在请查询我的状态，该干啥就干啥。事实上，当CPU收到网卡中断的时候，它也不知道该干啥，它只会调用中断处理函数，其内部会去读取一写寄存器的状态，然后才能知道现在该干什么，比如可以发送数据包，比如收到一个数据包等。既然如此，即使在关中断的情形下，如果不依靠中断，CPU择机主动调用一下网卡的中断处理函数，读取一写寄存器的状态，是不是也能知道该干什么呢？答案当然是肯定的了！这就是netpoll的逻辑，它使用两步完成任务：
1.主动调用网卡的中断处理函数，获取当前该发送数据包还是接收到一个数据包；
2.直接hard_xmit数据包或者使用NAPI的接口去poll网卡的数据。
Linux netpoll的总体图示如下：
这个图示中附带了netconsole的原理，没想到他是如此的简单。我记得我曾经写过一个模块，将panic后的信息发到远端，这个是受到了一个xtables-addons模块的启发，起初失败了，但是最后我仔细debug了内核代码后，成功了。在成功的过程中，发现了很多以前不知道的东西。但是现在看看netconsole吧，它什么复杂的东西都不需要，只需要两步：
1.注册一个console，此后内核buffer的信息就会发到这个console；
2.该console下接netpoll的netpoll_send_skb，此后由netpoll逻辑来处理。
即便在panic后，中断已经被关了，甚至中断控制器都关闭的情况下，只要网卡没有进水，数据依然可以收发，它完全不依赖中断和协议栈。这简直太棒了！关于netconsole，我写多少都不如内核的Document来的好：$kernel/Documentation/networking/netconsole.txt.