Problem s overruns/rx_fifo_errors

pm-conf na kostax.cz pm-conf na kostax.cz
Čtvrtek Březen 16 13:17:30 CET 2017


Ja obcas podobne veci resil na FreeBSD a od te doby TSO na intel 
sitovkach (vlastne i jinych) vypinam a mam klid.

Petr Macek

Dne 16.3.2017 v 12:57 Adam Pribyl napsal(a):
> 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
> _______________________________________________
> Linux mailing list
> Linux na linux.cz
> http://www.linux.cz/mailman/listinfo/linux


Další informace o konferenci Linux