1.背景
5.關鍵路徑
目前收包存在的問題：
第一：inpterrupt livelock, 當收到包的時候，網卡驅動程序就會產生一次中斷。在大流量的情況下，操作系統將花費大量時間用於處理中斷，而只有
少量的時間用於其他任務。
第二：將包從網卡移動到用戶層花費的時間太久。
2.PF_RING的目標
1. 充分利用 device polling 機制
2. 減少內核開銷，開辟一條新的通道將收包從網卡傳輸到用戶態
其架構圖如下：
PF_RING實現功能如下：
1. 創建一種新的套接字類型 PF_RING, 用於將收包拷貝到一個環形緩沖區
2. 環形緩沖區和PF_RING套接字一同創建和銷毀，各個緩沖區為套接字私有
3.如果一個網卡適配器被PF_RING套接字利用系統調用bind()綁定，這個網卡只能用於只讀直到套接字銷毀
4.對於PF_RING套接字，收包將會被拷貝到套接字緩沖區或被丟包
5.套接字緩沖區將會利用mmap功能
6.用戶態程序通過mmap()系統調用訪問套接字緩沖區
7.內核拷貝包到環形隊列並移動寫指針，用戶態程序讀包並移動讀指針
8.新來的包將會覆蓋原有包，因此不需要進行內存的分配和釋放
9.套接字的緩沖區的長度和桶大小可被用戶配置
3.實驗效果
使用PF_RING之前：
使用PF_RING之后：
以上依然有丟包主要是因為用戶態程序阻塞在poll()，可通過內核補丁優化。
4.PF_RING 模式1和2的實現
處理流程圖：
5.關鍵路徑
函數igb_clean_rx_irq的內部實現：
第8080行函數nap_gro_receice實際上是一個宏：
#define napi_gro_receive(_napi, _skb) netif_receive_skb(_skb)
函數netif_receive_skb分析分組類型，以便根據分類類型將分組傳遞到網絡層的接收函數，為此該函數遍歷所有可能負責當前
分組類型的所有網絡層函數，這樣的話就將包發送至了內核協議棧。而第8075行的函數pf_ring_handle_skb函數將調用PF_RING的注冊函數進行處理。
6.考慮方案
在函數igb_clean_rx_irq增加包過濾函數，UDP且端口53發送至PF_RING處理，而其余包走內核協議棧。
7.需要考慮的問題
- 修改網卡驅動且需要維護多個網卡驅動
- 性能上不一定能到達DPDK的效果，因為DPDK丟棄了無關包
- PF_RING的發包需要使用DNA技術，而此功能需要費用。如果不使用DNA,發包將會走協議棧
- PF_RING是否對驅動進行了優化
備注：DNA功能和普通PF_RING比較減少一次內存拷貝
8.待做實驗
實驗目的：驗證模式0，1，2之間的差異
參考文獻：
Improving Passive Packet Capture: Beyond Device Polling - Luca Deri