作者：dnk_admin 發佈：2012-06-04 21:50 分類：開發經驗, 軟件使用經驗
繼《tcpdump之“亂”象？ | DNK的博客》===>
我作了下述實驗：
Dell 2850(as5.5) + e1000， tcpdump無亂序；
Dell 2950(as5.5) + bnx2，tcpdump無亂序；
Dell R720(centos6.2) + igb, tcpdump亂序。
呵呵，同樣是千兆的網卡，igb的表現出位啊。
當前系統使用igb驅動的網卡設備名是em3；CPU邏輯核數是24個。
cat /proc/interrupts | grep em3, 從結果可以分析出，em3共申請了24個rx隊列與24個tx隊列。
每個rx隊列，中斷數量幾乎一致，應該是被均攤到各個CPU邏輯核；由於是作抓包功能，tx隊列幾乎沒有產生什麼中斷。
查看/sys/class/net/em3/queue/目錄，其下有rx-[0…23]、tx-[0…23]共48個文件。
看來，igb爲每個設備申請了每CPU獨佔的隊列，抓包時，可以從報文到達網卡開始就進行高度並行的中斷處理。
也正是因爲高度併發的每CPU[硬中斷->rx隊列->軟中斷]機制，使得tcpdump抓到的報文順序看起來是亂的。
爲了驗證以上分析，特地修改了igb的驅動代碼，將每個設備申請的rx隊列與tx隊列調整爲1；
調整方法是：將igb.h裏IGB_MAX_RX_QUEUES、IGB_ABS_MAX_TX_QUEUES、IGB_MAX_TX_QUEUES三個宏的値全部改爲1。
奇怪的是，tcpdump現在不亂序了，但是表現爲丟包。
繼續折騰折騰，在igb的驅動代碼裏看到gro相關的東西：igb_main.c的igb_clean_rx_irq_adv函數，多個數據包通過skb_fill_page_desc接口追加到一起。
記得我以前在小改協議棧的時候，看過一段gro相關的代碼；拜訪了google，更具體的瞭解到，一些高級網卡爲了提升網絡的影響時間與呑吐量，支持gso/tso/ufo/gro之類的功能。
經過評估，很可能就是這個gro機制，使得某些相關聯的報文“粘”成一個，所以表現出丟包。
通過ethtool -K em3 gro off，將網卡的gro功能關閉，再測試，tcpdump抓包的時候，終於不亂序也不丟包了。
至此，終於平定了igb之“亂”；也爲tcpdump平反，嚴格來說，亂序不是tcpdump引起的。
至於《tcpdump之“亂”象？ | DNK的博客》提及的ixgb之“亂”，經過初步評估(中斷分佈、隊列分佈)，判斷其與igb屬相同性質，後續有時間再來研究把玩論證囉。
——————————————————————————————————————
末了，殺個回馬槍，如果只關閉igb的gro，而不將限定rx隊列與tx隊列爲1的話，tcpdump抓包還是亂序的。
其實，平定igb之“亂”的方法，在保證tcpdump抓包功能表現正常之餘，它的最大弊端就是，將提升性能的精髓部分抹掉了，這在非常關注網絡性能的場合，萬萬使不得的，除非論證後抓包性能不是瓶頸；本文所述的方法，純粹只是研究把玩一下。
話說，人家bnx2及e1000也千兆的，倒是挺中規中矩，沒有使用每CPU[硬中斷+隊列+軟中斷]的高深玩意；不過三者的性能倒是沒有作過對比。理論上，igb可能更勝一籌。
本文固定鏈接: http://www.danoking.com/2012/06/04/%e5%b9%b3%e5%ae%9aigb%e4%b9%8b%e4%b9%b1/ | DNK的博客
該日誌由 dnk_admin 於2012年06月04日發表在 開發經驗, 軟件使用經驗 分類下， 你可以發表評論，並在保留原文地址及作者的情況下引用到你的網站或博客。
原創文章轉載請註明: 平定igb之“亂” | DNK的博客