NAPI技術學習
以往的linux中，對底層的硬件模塊調用和響應，一般是採用了中斷技術或者是輪詢方式。而在當今信息技術發展的時候，網絡數據流量在不同場景下的負載差別越來越大，流量大小越來越複雜，單獨採用其中任何一種技術都不能很好的處理網絡流量。
中斷模式
採用中斷模式的網絡封包處理方式在小流量和中流量當中，顯得遊刃有餘。而且對系統的負載算是比較輕，數據流量在前一個數據包處理完之前就已經處理完畢。如果處於大流量的場景下，中斷模式就顯得有些力不從心，反覆的中斷請求往往是在當前包未處理完的情況下不斷的出現，要麼從一箇中斷中調到另一箇中斷，要麼就是不停的累積中斷請求，這樣的情況下，僅僅只是中斷跳轉也是很大一部分性能消耗，更別提處理數據封包的函數性能消耗。
輪詢模式
採用輪詢模式的網絡封包在大數據量的場景中倒顯得更加優越一些，由於收包緩存區是環形緩存區，輪詢方式可以將不停添加到緩存區的封包，遍歷處理，比起中斷處理方式，輪詢沒有跳轉和保存現場的性能消耗，可以使處理函數的性能接近100%。但是這也僅僅限於大量流量的情況下，在小數據量和中數據量的情況下，開着一個輪詢進程或線程本身就是對處理器資源的一種消耗，在大數據量的過程中，由於數據量的多，可以很好的將輪詢的優點凸顯，缺點掩蓋。小數據量的時候，則暴露無遺。
NAPI方式
既然中斷模式和輪詢模式各有各的特點，也各有各的處理部分擅長，如果我們能預先估計當前系統的流量大小，那麼我們是不是就可以直接自己指定其中一種作爲我們的流量處理方式？在單純的網絡流量特別大，類似服務器，或者流量比較小，客戶端的模式，我們是可以指定處理模式來優化我們的系統。但是在現代，我們有了一種新的技術-NAPI技術—來自適應流量大和流量小的情況。
NAPI使用了一種中斷加輪詢的方式來處理數據包，即當有數據包來的時候，系統會響應中斷處理函數，中斷函數中會自動屏蔽再次中斷請求，當包處理完成之後，中斷函數不會立即返回，而是對隊列進行一次輪詢，如果還有數據包，那麼就接着處理，一直到處理完畢，才返回。這樣就兼顧了輪詢和中斷的優點，數據量小的時候，系統cpu消耗小，數據量大的時候，能夠及時應付所有處理的包。同時對數據量波動很大的情況下也能適配。
個人學習NAPI的時候的一種愚見，歡迎指正