linux下napi学习

NAPI技术学习

以往的linux中，对底层的硬件模块调用和响应，一般是采用了中断技术或者是轮询方式。而在当今信息技术发展的时候，网络数据流量在不同场景下的负载差别越来越大，流量大小越来越复杂，单独采用其中任何一种技术都不能很好的处理网络流量。

中断模式

采用中断模式的网络封包处理方式在小流量和中流量当中，显得游刃有余。而且对系统的负载算是比较轻，数据流量在前一个数据包处理完之前就已经处理完毕。如果处于大流量的场景下，中断模式就显得有些力不从心，反复的中断请求往往是在当前包未处理完的情况下不断的出现，要么从一个中断中调到另一个中断，要么就是不停的累积中断请求，这样的情况下，仅仅只是中断跳转也是很大一部分性能消耗，更别提处理数据封包的函数性能消耗。

轮询模式

采用轮询模式的网络封包在大数据量的场景中倒显得更加优越一些，由于收包缓存区是环形缓存区，轮询方式可以将不停添加到缓存区的封包，遍历处理，比起中断处理方式，轮询没有跳转和保存现场的性能消耗，可以使处理函数的性能接近100%。但是这也仅仅限于大量流量的情况下，在小数据量和中数据量的情况下，开着一个轮询进程或线程本身就是对处理器资源的一种消耗，在大数据量的过程中，由于数据量的多，可以很好的将轮询的优点凸显，缺点掩盖。小数据量的时候，则暴露无遗。

NAPI方式

既然中断模式和轮询模式各有各的特点，也各有各的处理部分擅长，如果我们能预先估计当前系统的流量大小，那么我们是不是就可以直接自己指定其中一种作为我们的流量处理方式？在单纯的网络流量特别大，类似服务器，或者流量比较小，客户端的模式，我们是可以指定处理模式来优化我们的系统。但是在现代，我们有了一种新的技术-NAPI技术—来自适应流量大和流量小的情况。

NAPI使用了一种中断加轮询的方式来处理数据包，即当有数据包来的时候，系统会响应中断处理函数，中断函数中会自动屏蔽再次中断请求，当包处理完成之后，中断函数不会立即返回，而是对队列进行一次轮询，如果还有数据包，那么就接着处理，一直到处理完毕，才返回。这样就兼顾了轮询和中断的优点，数据量小的时候，系统cpu消耗小，数据量大的时候，能够及时应付所有处理的包。同时对数据量波动很大的情况下也能适配。

个人学习NAPI的时候的一种愚见，欢迎指正