David Pasek wrote on 13.04.2025 18:49:
Zjistil jsem, ze FreeBSD vmx interface defaultne nepouziva LRO (Large
Receive Offload)
Matne si pamatuju, ze je to proto, ze nektere karty (mozna tez v
zavislosti na firmware) nemaji vsechny HW akcelerace implementovane
spravne, a pri nekterych kombinacich to pak priste nesituje.
V situaci, kdy mi nekdo cizi tisic kilometru daleko strka na jakysi
stroj defaultni instalaci abych z na dalku, udelal telefonni ustrednu,
potrebuju aby to v defaultu bylo predevsim spolehlive a ja se na to po
jeho instalaci dostal. Hlavne abych tam nemusel letet. Na konkretni druh
zateze si to uz vyladim.
po enablovani LRO na vmx interfacu jsem byl schopen dosahnut
7,29 Gb/s, coz je vyrazne lepsi nez 1,34 Gb/s, ale porad mene nez 9,5
Gb/s na Debianu.
To je ta neprijemnost "defaultni instalace". FreeBSD GENERIC ma v sobe,
pokud vim, zakompilovane ipfw. Jak Debian nevim. Nevim jak vyjde
porovnani moznosti firewallu na obou systemech - ale neni asi treba
slozite vysvetlovat, ze implementace firewallu a HW akcelerace jsou dve
veci, ktere se ovlivnuji - firewall muze resit jen to, co se k nemu
dostane. Nebo, z opacneho uhlu pohledu, firewall musi zabranit nekterym
akceleracim aby se k nemu dostalo co potrebuje.
To je ohromny prostor na implementacni rozdily mezi systemy. Ale zejmena
- je to ohromny prostor pro to jak je system nastaveny v "defaultnim stavu".
Coz je nakonec videt uz na tom (ne)aktivnim LRO v jednom a druhem systemu.
Univerzalni pneumatiky jsou taky kompromisem, ktery funguje jak v zxime
tak v lete, ale ani v jednom obdobi nefunguje tak dobre, jako pneumatiky
vypadene pro to konkrenti obdobi. A i mezi temi univerzaly najdes
takove, ktere maji lepsi vlastnosti pri nizsich teplovath a jine, tkere
je maji lepsi pri teplotach vyssich.
Z meho pohledu, vysledek prezentovaneho testu rika, ze pri vyberu
"defaultniho nastaveni" se v Debianu vic soustredili na velky sitovy
tok, kdezto ve FreeBSD hraly prim jina kriteria.
Ale co s tim systemem lze dokazat, kdyz je pro dany styl pouzivani
nastaveny spravne to az tak moc nerika.
na consumer PC-ckach dosahuju vyssich sitovych propustnosti nez na
serverech, ale to plati jak pro FreeBSD, tak pro Debian
To muze nastacovat, ze dostupne open-source ovladace neumi plne vyuzit
specialnich vlastnosti serverovych sitovych karet.
Chtel jsem se zeptat co si o tom myslite, jestli nekdo provozujete
FreeBSD pro velke sitove toky a jestli mate na sitovych interfacech
nastavene LRO a jestli pouzivate Jumbo Frames (MTU 9000).
Od konce - ne, ano (pokud v dane konfiguraci funguje), ne az tak uplne.
Large MTU obvykle nepouzivame, protoze MTU musi mit vsechny stroje v
dane L2 siti nastavene stejne. Jinymi slovy, MTU nemuze byt vetsi nez co
dovoli nejmene tolerantni komponenta. Dokonce i pro switch eplati, ze
neni samozrejme, ze umi 9000. Nektere konci u 8192, nektere dokonce u
4000. Ale u nas je v te siti nakonec prakticky vzdycky neco
"standardniho" co vic nez 1500 neda a tim je omezena MTU cele site.
Ale dovedu si predstavit L2 sit ve ktere je pouze datove pole a
databazovy server a jinak nic - a mezi nimi by Large MTU rozhodne smysl
mela. Jenze tohle nikde nemam.
A co se "velkejch sitovejch toku" tyce, je rozdil jestli se bavime o
FreeBSD na pozici routeru, tedy primarne L3 zarizeni, ktere funguje na
urovni IP paketu a vys nekouka a nebo jde o sitovy server, kde se ty
"velike toky" musi vyresit i z hlediska vyssich vrstev.
Kdyz se omezime na tu prvni variantu, zadny genericky OS nedokaze byt
tak rychly jako specializovany HW router, ve kterem casove/vykonove
nejkritictejsi cast cinnosti sverena hradlovemu poli. Takze FreeBSD,
Debian a v podstate cokoliv generickeho je dobra low-cost varianta, ale
nikde se mi nepotkava situace, ze by nekdo mel prachy na rychlou L1/2
infrastrukturu, ale nemohl by si dovolit i odpovidajici router.
A pokud jde o aplikacni servery s vysokym tokem - zatim jsem vzdycky
driv narazil na limity diskoveho subsystemu driv, nez me dohnaly limity
site, takze v tehle oblasti vlastni zkusenosti moc nemam.
Pro zajimavost odkazu na dva dokumenty, ktere ukazuji, ze FreeBSD umelo,
a to uz v pred radou let, zvladnout daleko vetsi toky nez o kterych tu
je rec:
https://www.chelsio.com/wp-content/uploads/resources/T5-NIC-40Gb-FreeBSD.pdf
A to se standartni MTU.
Cimz nechci vyvolat flameewar o tom jestli je lepsi FreeBSD nez Debian,
jako spis ukazat na urcity rozdil ve filosofii. Problemy lze resit dvema
zpusoby - koupim si nejakej generickej nabusenej HW (pripadne dokonce
ani to ne a strci se to do nejakeho virtualizatoru), nainstaluju na nej
nejakej generickej system v defaultnim nastaveni - a verim, ze na tom
udelam cokoliv co potrebuju.
Tak v tomhle FreeBSD uplne nekraluje. Jeho "defaultni" hodnoty casto
budu horsi, nez defaultni hodnoty jinych systemu.
Druha moznost je, ze zacinam nejakym zadanim. Takze tusim co potrebuju.
Tomu prizpusobim vyber HW i SW konfiguraci systemu. A pri tomhle
pristupu se s FreeBSD dokazu dostat na vysledky, ktere jine genericke OS
ani pres veskere ladeni parametru nedostanou.
A proto se lze potkat s lidmi, kteri tvrdi, ze FreeBSD je v oblasti
sitovani spicka, stejne jako s lidmi, kterym testy ukazuji neco jineho.
A obe skupiny, jak ta, ktera si pro zadani zvoli a prizpusobi nastroj,
tak ta, ktera se omezuje na vyber z nabizenych nastroju a ty uz
neprizpusobuje, maji ve svem svete pravdu.
Dalsi dotaz je, jestli nekoho nenapada neco dalsiho co by se dalo na
FreeBSD vytunit, aby se zvysila sitova propustnost. Jeste me napada
enablovat RSS, ale to neni enabovane ani na Debianu ani na FreeBSD.
Receive Side Scaling zajistuje, ze prichozi pakety se v sitove karte
radi do nekolika front z nichz kazdou muze nezavisle (v limitu celkove
kapacity sbernice) zpracovavat jiny procesor (v porovnani s beznym
non-RSS provozem, kdy data z karty vycita procesor jeden).
Cilem RSS je dosahnout toho, aby TCP resp. UDP data z karty vycitat
stejny procesor, ktery je nasledne bude na aplikacni urovni zpracovavat
(cimz se mohou efektivne zapojit per-CPU cache). Uz z toho plyne, ze u
cisteho routeru nebude mit RSS zasadni efekt.
Zda ti RSS pomuze a jak moc zavisi zejmena na tom, jestli mas sitovou
kartu, ktera ho podporuje a podporu RSS ma i jeji systemovy ovladac. Ve
FreeBSD do tusim je v teto chvili pouze igb, ixgbe a snad jeste cxgbe
Brzdou je mj. chybejici podrobna dokumentace. Neni az takovy problem RSS
"zapnout". Neni ale jasne co presne to pak dela. Napriklad v pripade
fagmentovanych paketu. Kdyz je a kdyz neni soucasne zapnute LRO. A co
teprve, kdyz vedle IPv4 prichazi i IPv6.
V neposledni rade celkovy vysledek zalezi i na tom, jak moc je RSS-ready
aplikace, ktera toky zpracovava. I ona by mela bezet v tolika
paralernich vlaknech na kolika CPU se datove toky ctou ze sitove karty,
jinak cele kouzlo RSS nemusi prinest zadny viditelny efekt.
Dan
