Problem s overruns/rx_fifo_errors

[Dalibor Toman]

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