求助！關(guān)于82580網(wǎng)卡丟包的問(wèn)題

shamofeiyu

回復(fù) 30# smalloc


    我也懷疑是驅(qū)動(dòng)的多核處理問(wèn)題，但是沒(méi)能找到具體的地方，我使用了PF_RING這個(gè)開(kāi)源的抓包庫(kù)

shamofeiyu

回復(fù) 26# 帥絕人寰


    如果是CPU性能不夠或者buffer滿(mǎn)，網(wǎng)卡的FIFO沒(méi)能及時(shí)獲取，那網(wǎng)卡丟包計(jì)數(shù)應(yīng)該能反映出來(lái)啊，但是現(xiàn)在都沒(méi)有。我用的PFRING的抓包庫(kù)，我在網(wǎng)卡驅(qū)動(dòng)中加的連續(xù)計(jì)數(shù)值都有問(wèn)題，所以懷疑是PF_RING出的問(wèn)題

帥絕人寰

如果網(wǎng)卡硬件statistics沒(méi)有統(tǒng)計(jì)，那么是2層filter給丟掉了， 連driver都沒(méi)到。

例如， 多播包，但你的 multicast table沒(méi)match上

例如，沒(méi)開(kāi)promisc模式的情形下， 目的mac不是本機(jī)、也不在unicast table中的包。

例如， vlan 包


反正只要卡真的收了，真的發(fā)出中斷了， 那么硬件就應(yīng)該統(tǒng)計(jì)上它。

Godbach

回復(fù) 26# 帥絕人寰
老帥的回復(fù)總是那么一如既往的經(jīng)典


   

shamofeiyu

回復(fù) 33# 帥絕人寰


    謝謝答復(fù)，丟包問(wèn)題解決差不多一半了，有兩個(gè)丟包環(huán)節(jié)：
1.PF_RING這個(gè)開(kāi)源的抓包框架出現(xiàn)了問(wèn)題，在D525上，主要是應(yīng)用層讀buffer讀空后沒(méi)有停下來(lái)，導(dǎo)致讀出的數(shù)據(jù)是錯(cuò)誤的了；
上面這個(gè)是最開(kāi)始提問(wèn)的問(wèn)題，可以說(shuō)解決了，之后還發(fā)現(xiàn)了下面這個(gè)問(wèn)題，也已經(jīng)解決，下面這個(gè)是可以通過(guò)ifconfig 中 的drop體現(xiàn)的。
2.82580網(wǎng)卡驅(qū)動(dòng)igb 3.2.10中存在一個(gè)bug,極端情況下申請(qǐng)的buf會(huì)越來(lái)越少，DMA環(huán)中可用的描述符會(huì)原來(lái)越少，最后就出現(xiàn)丟包了；

以上這些出現(xiàn)丟包都解決了。但是現(xiàn)在還有個(gè)問(wèn)題，就是瞬間會(huì)有大量的網(wǎng)卡drop,而且比較難復(fù)現(xiàn)，可能連續(xù)運(yùn)行兩三天才會(huì)出現(xiàn)，
感覺(jué)是丟包那一刻CPU停止工作了，現(xiàn)在懷疑是不是跟電源管理有關(guān)