linux下napi學習

NAPI技術學習

以往的linux中，對底層的硬體子產品調用和響應，一般是采用了中斷技術或者是輪詢方式。而在當今資訊技術發展的時候，網絡資料流量在不同場景下的負載差别越來越大，流量大小越來越複雜，單獨采用其中任何一種技術都不能很好的處理網絡流量。

中斷模式

采用中斷模式的網絡封包處理方式在小流量和中流量當中，顯得遊刃有餘。而且對系統的負載算是比較輕，資料流量在前一個資料包處理完之前就已經處理完畢。如果處于大流量的場景下，中斷模式就顯得有些力不從心，反複的中斷請求往往是在目前包未處理完的情況下不斷的出現，要麼從一個中斷中調到另一個中斷，要麼就是不停的累積中斷請求，這樣的情況下，僅僅隻是中斷跳轉也是很大一部分性能消耗，更别提處理資料封包的函數性能消耗。

輪詢模式

采用輪詢模式的網絡封包在大資料量的場景中倒顯得更加優越一些，由于收包緩存區是環形緩存區，輪詢方式可以将不停添加到緩存區的封包，周遊處理，比起中斷處理方式，輪詢沒有跳轉和儲存現場的性能消耗，可以使處理函數的性能接近100%。但是這也僅僅限于大量流量的情況下，在小資料量和中資料量的情況下，開着一個輪詢程序或線程本身就是對處理器資源的一種消耗，在大資料量的過程中，由于資料量的多，可以很好的将輪詢的優點凸顯，缺點掩蓋。小資料量的時候，則暴露無遺。

NAPI方式

既然中斷模式和輪詢模式各有各的特點，也各有各的處理部分擅長，如果我們能預先估計目前系統的流量大小，那麼我們是不是就可以直接自己指定其中一種作為我們的流量處理方式？在單純的網絡流量特别大，類似伺服器，或者流量比較小，用戶端的模式，我們是可以指定處理模式來優化我們的系統。但是在現代，我們有了一種新的技術-NAPI技術—來自适應流量大和流量小的情況。

NAPI使用了一種中斷加輪詢的方式來處理資料包，即當有資料包來的時候，系統會響應中斷處理函數，中斷函數中會自動屏蔽再次中斷請求，當包處理完成之後，中斷函數不會立即傳回，而是對隊列進行一次輪詢，如果還有資料包，那麼就接着處理，一直到處理完畢，才傳回。這樣就兼顧了輪詢和中斷的優點，資料量小的時候，系統cpu消耗小，資料量大的時候，能夠及時應付所有處理的包。同時對資料量波動很大的情況下也能适配。

個人學習NAPI的時候的一種愚見，歡迎指正