napi技術(shù)在linux網(wǎng)絡(luò)驅(qū)動上的應(yīng)用和完善-資料下載頁
2025-07-13 20:42本頁面
【正文】 前的cur_rx和dirty_rx之間相差不超過總的rx_ring接收單元的一半， 而且剩下的一半中間有空的傳輸單元，那么我們不必擔心了，因為還有足夠的緩沖區(qū)可以使用（憑經(jīng)驗推斷的）， 就可以退出當前的程序，等待下一次軟中斷調(diào)用POLL來處理在這之間收到的數(shù)據(jù)， （，這樣做是在沒有使能NIC中斷處理的情況下）*/ if (tprx_buffers[tpdirty_rx % RX_RING_SIZE].skb == NULL) restart_timer()?！ ?*如果執(zhí)行到這里了，那表示有幾種情況可能發(fā)生，第一當前的cur_rx和dirty_rx之間相差不超過總的rx_ring接收單元的一半， 調(diào)用refill_rx_ring后dirty_rx并未增加，（也許在rxring中大量的單元收到數(shù)據(jù)沒有得到網(wǎng)絡(luò)層函數(shù)的處理）， 結(jié)果dirty_rx沒有增加，而且也沒有空閑的單元來接收新到的數(shù)據(jù)，這樣就要重新調(diào)用netif_rx_schedule 來喚醒軟中斷， 調(diào)用設(shè)備的POLL方法，采集在rxring的數(shù)據(jù)。*/ else netif_rx_schedule(dev)。 /* we are back on the poll list */ 在 RTL8169 的驅(qū)動程序中就使用了 dirty_rx 這個字段，但是在 8139CP 中并未使用，其實這個并非 8139CP 驅(qū)動不成熟的表現(xiàn)，大家閱讀 中可以知道，現(xiàn)在 8139CP 中并未嚴格按照 NAPI 所提出的要求去做，如果大家有興趣的話，可以比較一下 8139CP 和 RTL8169 這兩個驅(qū)動之間的不同，大家會發(fā)現(xiàn)雖然兩者都沒有在 NIC 中斷處理中去完成數(shù)據(jù)從驅(qū)動層向網(wǎng)絡(luò)層上的轉(zhuǎn)發(fā)，而都放在了軟中斷之中完成，但是在 8139 中利用了自己的一些獨特的硬件特性，使 NIC 在利用關(guān)斷中斷接收數(shù)據(jù)的同時利用數(shù)據(jù)包到達位（RxOK）通知到達事件，然后采用 POLL 方法把數(shù)據(jù)從 NIC 直接轉(zhuǎn)發(fā)到上層；而 RTL8169 還需要借助 softnet_data 結(jié)構(gòu)中的 input_pkt_queue（套接字緩沖（sk_buff）輸入隊列）來完成從 NIC 中斷到軟中斷之間的 sk_buff 數(shù)據(jù)調(diào)度；這樣對于 8139CP 來說最大的好處就是不要了 dirty_rx 字段和 cur_rx 字段來讓 POLL 方法以及 NIC 中斷知道當前的傳輸單元的狀況，還包括不需要不時定期的調(diào)用 refill_rx_ring 來刷新 rxring 獲得空閑的傳輸單元；說到壞處我想就是重寫了一個 POLL 方法，完全不能借用 /net/core/ 中的 process_backlog 來作為自己的POLL方法，不過這個代價值得?！ ≌f了這么多，似乎都和提高效率沒有關(guān)系，其實正好相反，通過這些了解我們對 softnet_data中的一些字段的意思應(yīng)該更加清晰了，下面所敘述的，提高效率的方法就是在 8139CP 的基礎(chǔ)上借用了 NAPI_ 中的一些方法，從實際上的使用效果來看，在某些應(yīng)用場合之下比 Linux的 8139CP 的確是有了一定的提高，我們首先看看在 的內(nèi)核使用 8139CP 在x86(PIII900Mhz)平臺上的數(shù)據(jù)包接收處理情況：比較表如下： Psize Ipps Tput Rxint Done 60 490000 254560 21 10 128 358750 259946 27 11 256 334454 450034 34 18 512 234550 556670 201239 193455 1024 119061 995645 884526 882300 1440 74568 995645 995645 987154 上表中表示： Pszie表示包的大小 Ipps 每秒鐘系統(tǒng)可以接收的包數(shù)量 Tput 每次POLL超過 1M 個數(shù)據(jù)包的總量 Rxint 接收中斷數(shù)量 Done 載入 rxring 內(nèi)數(shù)據(jù)所需要的 POLL 次數(shù)，這個數(shù)值也表示了我們需要清除 rxring 的次數(shù)。 從上表可以看出，8139CP 中當接收速率達到 490K packets/s 的時候僅僅只有 21 個中斷產(chǎn)生，只需要 10 次 POLL 就可以完成數(shù)據(jù)從 rx_ring 的接收，然而對于大數(shù)據(jù)包低速率的情況，接收中斷就會急劇增加，直到最后每個數(shù)據(jù)包都需要一次 POLL 的方法來進行處理，最后的結(jié)果就是每個中斷都需要一次 POLL 的方法，最后造成效率的急劇下降，以至于系統(tǒng)的效率就會大大降低，所以 NAPI 適用于大量的數(shù)據(jù)包而且盡可能是小的數(shù)據(jù)包，但是對于大的數(shù)據(jù)包，而且低速率的，反而會造成系統(tǒng)速度的下降?！ ∪绻纳七@種情況，我們可以考慮采用以下的方法，我們在 MIPS，Xsacle 和 SA1100 平臺上進行一系列的測試取得了良好的效果： 1． 完全取消 NIC 中斷，使用 RXOK 位置控制接收中斷， 2． 采用定時器中斷 timer_list 的控制句柄，根據(jù)硬件平臺設(shè)定一個合適的間隔周期（間隔周期依據(jù)平臺不同而異），對 rxring 直接進行 POLL 輪詢，我們在 MIPS 和 Xscale 上直接使用了中斷向量 0irq0 作為對 rxring 進行輪詢的 tophalf（注意我們在上述兩個平臺上選擇的 HZ 數(shù)值是 1000,而通常這個數(shù)值是 100，并且重新編寫了 Walltime 的記數(shù)程序，讓 WallTime 的記數(shù)還是以 10MS 為間隔），當然也可以根據(jù)自己的平臺和應(yīng)用程序的狀況選擇合適的定時時間?！ ?． 借助 softnet_data 中的 input_pkt_queue 隊列，在時鐘中斷 bottomhalf 中完成 POLL 方法之后，并不直接把數(shù)據(jù)傳輸?shù)骄W(wǎng)絡(luò)層進行處理，而是把 sk_buff 掛在 input_pkt_queue隊列上，喚醒軟中斷在過后處理，當然可以想象，這樣需要付出一定的內(nèi)存代價，而且實時性能也要差一些。 4． 使用 dirty_rx 字段和 refill_rx_ring 函數(shù)，在調(diào)用完 POLL 方法以后，而且網(wǎng)絡(luò)層程序比較空閑的時候為一些 rxring 中的單元建立新緩沖掛在環(huán)形緩沖隊列上，這樣可以在新的數(shù)據(jù)包達到的時候節(jié)省時間，操作系統(tǒng)不必要手忙腳亂地開辟新的空間去應(yīng)付新來的數(shù)據(jù)?！ ?． 最后請注意：我們上層的應(yīng)用程序是以網(wǎng)絡(luò)數(shù)據(jù)轉(zhuǎn)發(fā)為主的，并沒有在應(yīng)用層面上有很多后臺進程的復(fù)雜的應(yīng)用，上述的 1 到 4 點中所做的顯而易見是以犧牲系統(tǒng)效率整體效率而單獨改善了網(wǎng)絡(luò)數(shù)據(jù)的處理?！ ∥覀冊賮砜锤纳频?8139CP 驅(qū)動程序使用 8139CP 在 x86(PIII900Mhz) 平臺上的接收情況： Psize Ipps Tput Rxint Done 60 553500 354560 17 7 128 453000 350400 19 10 256 390050 324500 28 13 512 305600 456670 203 455 1024 123440 340020 772951 123005 1440 64568 344567 822394 130000 從上圖來看，數(shù)據(jù)傳輸?shù)男屎筒▌有杂泻苊黠@的改善，在高速率和低速率的時候所需要的POLL 次數(shù)的差距以前的 8139CP 驅(qū)動程序那么顯著了，這樣的而且最大的包接收能力也提高到了 553K/s，我們在 MIPS 系列以及 Xscale 系列平臺上最大的包接收能力可以提高大約 15%25%?！ ∽詈笫褂?NAPI 并不是改善網(wǎng)絡(luò)效率的唯一途徑，只能算是權(quán)益之策，根本的解決途徑還是在于上層應(yīng)用程序能夠獨占網(wǎng)絡(luò)設(shè)備，或者是提供大量的緩沖資源，如果這樣，根據(jù)我們的實驗數(shù)據(jù)表明可以提高 100%150% 以上的接收效率。14 /
醫(yī)療健康相關(guān)推薦
鄂ICP備17016276號-1