FreeBSD 14.2 tcp throughput

[Dan Lukes]

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