További teljesítmény javulások várhatók pf fronton (hardver kerestetik)

OpenBSD

A nemrég lezajlott OpenBSD-s HackAthon alatt Henning Brauer többször is javított az OpenBSD csomagszűrőjének, a pf-nek a teljesítményén. Az egyik commit után az előzetes tesztek 50% körüli javulást mutattak. A HackAthon végetért, Henning visszatért Hamburgba, de mint írja, lenne még ötlete a további hálózatos fejlesztésekre, de munka végzéséhez hardverre lenne szükség. Szóval, ha van valakinek két darab 1U magas, lehetőleg egyforma, egy processzoros gépe elfekvőben Hamburg környékén, és szívesen segítene, az dobjon levelet a henning@ és deraadt@ email címekre. További részletek itt.

( godot v | 2007. 06. 13., sze – 19:37 )

Gyerünk VRF+MPLS kell bele és már dobjuk is a Cisco-t.

Jól érzem, hogy itt valami routingról van szó? Ráadásul ha VRF és MPLS, akkor akár valami komolyabbról? Ha igen, akkor hol ér fel egy router forwardolási teljesítményével egy PC-s OpenBSD?

Ehh, ezeket a VRF és MPLS dolgokat nem igazán érzem PC kompatibilisnek.

Leírnád kicsit bővebben a környezetet?

Kurva drágán árult CE (CPE) routernek pozicionált CISCO routereket ki lehetne váltani vele.
Mondjuk konrétan a 28xx sorozatra gondoltam, de akár 38xx is.

Egyébként foglalkoznak a dologgal lásd legutobbi Onlamp interjú:

PF is only a piece in the concept of multiple routing tables. PF is "just" used as packet classifier similar to altq. This makes it possible to classify the traffic and selecting different tables to route that traffic. Using multiple routing tables together with bgpd enables OpenBSD to implement customer VPNs in ISP networks--in Cizzz-coeee speak VRF-lite (virtual router forwarding). 4.1 only includes basic support--PF can be used as classifier and it is possible to specify the table that bgpd should use. There is still a lot missing but OpenBSD is about evolution and not revolution. Expect to get more and better support in the next release.

De linux fronton már előrébb vannak:

http://linux-vrf.sourceforge.net/
http://mpls-linux.sourceforge.net/

Üdv
Godot

( bastya_elvtars | 2007. 06. 13., sze – 20:09 )

A jelenlegi gépek nem alkalmasak a DragonFly CVS-tree checkoutolásához? ;-)
It doesn't matter if you like my song as long as you can hear me sing

Amennyire tudom a netfilter sem igazán MP-bajnok, sőt úgy általában a hálózati feldolgozás skálázódásával is gondok vannak a legtöbb OS-ben.
Lásd pld. Solaris (lényegében újraírják az egészet a 10-estől), ahol azért ennek némileg nagyobb hagyománya volt, vagy akár a Linux, ahol még szintén van bőven tennivaló ahogy olvastam.

Ha nem akarsz stateful tűzfalat (:-), akkor - mivel minden tábláról, számlálóstul, minden CPU számára van egyedi másolat - nincs semmi gond SMP esetén. Ha akarod, akár minden hálókártyához dedikálhatsz egy CPU-t. De

  • stateful tűzfal esetén a kapcsolatokat kell kezelni, azt meg nem lehet minden egyes CPU-ra "másolni": sok és gyors RAM-al segíthetsz rajta. Az egyes CPU-k felől az egyetlen conntrack "táblához" való egyidejű hozzáférések miatt lock-olni kell, ez vezet egy természetes szűk keresztmetszethez.
  • a tűzfalazás nem igazán CPU igényes: inkább gyors busz kell a jó hálókártya felé (nyilván kivéve, ha CPU intenzív egyezéseket használsz, pl string match)

Szigorúan csak a netfilterről szólva.

Persze, igazából nagy forgalomnál jelenthet szűk keresztmetszetet. Volt rá elképzelés, hogy az egész állapottáblát felosztjuk régiókra, és régió-szintű lockolás folyik. Így jó eséllyel az történne, hogy két-több konkuráló CPU különböző régiókat lock-ol és szépen parallel végezhetik a dolgukat. Könnyen össze lehetne ütni.

De igazából két kritikus pont van: az egyik az új bejegyzések létrehozása. A leglassabb rész ez az inicializálások miatt. Nyilván minél kevesebbet kellene inicializálni és csökkentenünk a komplexitást, hogy minél gyorsabb legyen (gondolj DoS-ra).

A másik az, amikor tele az állapottábla és törölni kell belőle bejegyzéseket. Ha csak random próbálunk találni, akkor lehet, hogy semmit nem tudunk törölni. Ha az egész táblát végignyálazzuk, az lassú. Ha nyilvántartjuk a legrégebb létrehozott és nem felépült kapcsolatokat, akkor kreáltunk egy új potenciális szűk keresztmetszetet (konkurens hozzáférés több CPU-ról) és ütközünk az előző ponttal is.