TCP/IP:frame的接收方式之中断方式

   在学习TCP/IP时，不可避免地要理解接收frame的中断方式和轮询方式，以及两者的结合。为什么不坚持中断方式？因为在负载高时效率低，为什么低？因为中断频繁...等等。其实，如果我们理解了中断的过程，那么就很好理解了。

   首先，我们来看看中断方式相对于轮询方式的优点。

   由于我们不知道数据包什么时候会来，因此，为了能否在数据包来后及时的处理，所以要不停的去读状态看看数据来了没。显然，如果数据包不多，稀稀拉拉地来几个，那么我们就浪费了很多时间去检查这个状态。

   但是，对于中断方式来说，就不会存在浪费很多时间去检查状态。因为，内核完全可以做其他事情，当数据包来时就会触发一个硬件中断，然后内核转去处理中断，也就是接收数据。从这看来，中断方式似乎比轮询方式好很多。不过，这里其实是有个前提，就是前面说到的数据包是“稀稀拉拉”地来。如果数据包来的非常频繁，那么中断方式就有缺点了，为什么，请看下面的解释。

   linux处理中断的流程，以ARM平台为例。这里我只讲软件部分，硬件部分我不清楚，犹记得是触发各种电平...

   根据我的理解：中断处理过程与函数调用很像，尤其是入口和出口的地方。以汇编的方式理解C语言，这句话忘记在哪看的，感觉很经典。我们反汇编一个C程序，可以看到在函数入口处要建立栈帧，压寄存器，为局部变量分配栈空间；在函数返回处要恢复栈顶指针sp以及恢复寄存器。为什么要这么做？我觉得这个是软件工程的一个思想：keep it simple。为了减少麻烦，我把后面要用到的寄存器的值备份起来，后面随便用这个寄存器，完全不用担心会污染这个寄存器，用完后再恢复这个寄存器，非常简单。中断处理也是一样。中断来了，我去处理中断的一些事宜，处理完呢？处理完后我要再回来干中断来之前的事情，也就是要恢复到之前的上下文。那么什么是上下文？寄存器！所以，在中断处理中一个重要的环节就是把寄存器压到栈中，在做这件事时是不能再来中断的，所以要关掉本地中断。关掉中断以为着不会再响应后面的中断，中断是没有排队之说的。保存完寄存器后根据中断号去调用响应的中断处理程序，处理完后再把前面保存的中断前的寄存器恢复，同时打开中断，回到以前的上下文。在处理中断时，会开中断以及唤醒相应的软中断（这里会去处理数据包），然后再关中断去恢复寄存器。

   所以，采用中断方式时，如果数据包来得非常频繁，那么，软中断（处理数据包的地方）会频繁地被中断打断。打个比喻，在处理第一个包时，连续来了N个中断，这些中断毫不客气地打断了数据包处理。不巧的是，这N+1把接收队列塞满了，直接导致一方面接收队列一直保持满的状态（没有时间去处理数据包），另一方面后面来的数据包也无法接收。

   那么，怎么解决上面的问题呢？对，关网络设备的中断，这样，在处理数据包时就不会有中断来打断了。这个就是NAPI的一个思路。当然，NAPI的另外一个思路是加入轮询。这个后面再分享。

   由于本人正在学习，技术水平有限，如若有错误之处请不吝赐教。