Problem s overruns/rx_fifo_errors

[Adam Pribyl]

Podobne problemy jsme tusim na i210 meli kvuli TSO
ethtool -k eth0

https://forum.ivorde.com/linux-tso-tcp-segmentation-offload-what-it-means-and-how-to-enable-disable-it-t19721.html



On Thu, 16 Mar 2017, Dalibor Toman wrote:

> DD,
>
> resim takovy divny problem s narustajicim poctem poztracenych prijimanych 
> packetu na nekterych sitovkach. Mozna uz nekdo neco podobneho resil a poradi.
>
> - mam nekolik routeru (vsechno bezi na Scientific Linuxu 6.x), ktere mezi 
> paternim spojem a nejakou siti za routerem prehazuji packety, delaji nejaky 
> filtering pomoci iptables a shapuji pomoci htb.
> - vetsina routeru ma e1000e driver a na nich problem nepozoruji.
> - problem se zrejme vyskytuje jen na routerech s igb driverem. Pozoruju ho ve 
> vetsim meritku na 2 routerech, oba maji toky 1gbps+ (cca 100000pkts) jsou 
> osazeny sitovkami s lepsim chipsetem, ktery rozdeluje packety do front per 
> cpu jadro, irq mam rozhazene po jadrech. Jeden router pouziva chipset Intel 
> i210 (on board sitovky), druhy Intel 82576 (externi 2 portove sitovky), na 
> obou routerech jsou vytvorene 2 bondovane interfacy, vzdy ze 2 sitovek. 
> Jednotlive sitovky v bondech prenaseji cca stejne mnozstvi packetu
> - projevuje se to narazovym zvysovanim counteru 'overruns' ve vypisu 
> 'ifconfig ethx'. Cislo sedi s obsahem 'rx_fifo_errors' z 'ethtool -S ethx' a 
> 'rx_fifo_errors' zase sedi jako soucet jednotlivych 'rx_queue_Y_drops'. 
> Narazove znamena, ze se delsi dobu (klidne dny) nedeje nic a pak behem jedne 
> vteriny se ztrati (resp zapocita) par set az par desitek tisic packetu 
> najednou.
> - mam k dispozici grafy nekterych souvisejicich veci (rx packety, 
> rx_fifo_errors, cpu zatez, /proc/net/softnet_stat) odecitane kazdou sekundu. 
> Z nich je zatim videt, jen ze rx_fifo_counter najednou poskoci a nic dalsiho 
> podezreleho se nedeje. Zadny zvyseny tok packetu (nejaky silny burst, DDOS) , 
> pretizene CPU,..
>
> Informace, ktere jsem k problemu sehnal rikaji, ze by melo dochazet k 
> zaplneni kruhoveho bufferu pro packety, kam sitovka DMAckem uklada packety. 
> Na zaklade toho jsem zkousel
> - zvetsit ring buffer na sitovkach. Z defaultnich 256 packetu na 4096 pro RX. 
> Problem pretrvava dokonce se zda, ze od te doby se narazove ztraci vetsi 
> mnozstvi packetu
> - zvetsil jsem 'net.core.netdev_budget' aby SoftIRQ handler mol vyzvednout 
> vice packetu najednou ale nepomohlo. Poodle grafu navic malokdy nastane 
> situace, ze by SoftIRQ obsluha musela ukoncit praci drive nez vyprazdni RX 
> frontu a zatim to nikdy nenastalo v case, kdy se ztrati packety
> - cekal jsem, ze kdyz se ucpe fronta, bude se sitovka/driver snazit 
> signalizovat pomoci flow control switchi, ze ma zpomalit. Graf poctu 
> prijatych rxPause ramcu ze switche ale ukazuje, ze nic nechodi a i 'ethtool 
> -S ethx | egrep flow' ukazuje nuly. Pravda je, ze si nejsem jisty jak poznat 
> na linuxu, ze sitovka opravdu pouziva flowcontrol (switch tvrdi, ze je 
> povoleno ale mam nastaveno natvrdo ON). Switche zachazi s flowcontrol spravne 
> (zvysuje prislusne citace atd) - overeny na jinych portech s jinymi 
> pripojenymi zarizenimi
> - problem nastava v libovolnou denni dobu, nezda se, ze by byl zavisly na 
> mnozstvi provozu (je celkem jedno zda je spicka trafficu nebo utlum)
>
> Jeste jsem nezkousel zakazat vyssi sleep stavy CPUckum...
>
> Ve hre je take to, ze ten counter ze sitovky si vymysli. Nemam zatim nijak 
> potvrzeno, ze se nejake packety opravdu ztrati.
>
>
> Diky
> D. Toman