Netdev 0x13 beszámoló

 ( SPYFF | 2019. március 24., vasárnap - 21:22 )

A netdev (https://www.netdevconf.org/) egy szakmai konferencia, ahol a Linux kernel hálózati moduljaival kapcsolatos előadások, workshopok és tutorialok vannak. Bárki küldhet be saját előadást, ezt aztán egy szakmai bizottság (aktív commitolói a network stacknek) bírálja és fogadja- vagy utasítja el. Linuxra fejlesztő cégek is bemutatják a legfrissebb munkáikat, nem egyszer a konferenciára időzítve küldik be a patchsetet a bemutatott eredményekről. A továbbiakban egy élménybeszámoló következik a konferenciáról (főleg a szakmai dolgokra koncentrálva).

A konferencia teljes programja itt található: https://www.netdevconf.org/0x13/schedule.html

1. nap: Párhuzamosan ment négy track, én a TCP Analyticsre ültem be mert ez érdekelt a legjobban. A tcp_info új időbélyeg megoldásáról tartott előadást egy Google-nél dolgozó mérnök. Röviden összefoglalva arról van szó, hogy némi overhead mellett de a minket érdeklő kapcsolatoknál pontos időbélyegekkel tudjuk a csomagokat nyomon követni: send rendszerhívás kiadása, TCP stackben töltött idő + IP stackben és tc queueingban töltött idő, NIC driverbe való feladás ideje és az TCP ACK megérkezésének az ideje a fogadótól. Ezek után Lawrence Brakmo a TCP BPF alkotója mutatta be miket tud az új TCP BPF és mik várhatóak. Írhatunk BPF programokat, ami congestion eventekre reagálhat, módosíthatja a congestion control algoritmust vagy annak változóit, ECN-re reagálhat. Az Akamai egyik mérnöke bemutatta, hogyan gyűjtenek nagy méretekben TCP kapcsolat statisztikákat. A legtöbb újdonság TCP BPF oldalon várható a jövőben, volt egy előadás arról is, hogy ahelyett hogy sok obskúrus RFC-t implementálnánk a kernelbe (amiket aztán senki nem használna) a TCP BPF modult kellene még kicsit általánosítani annyira, hogy akinek kísérleti TCP kiterjesztéseket támogató RFC-ket szeretnének kipróbálni, akkor ők azon keresztül megtehessék (pl. TCP fejlécek módosítása bizonyos esetekben, azok bővítése kísérleti fejlécekkel). Még Lawrencetől megkérdeztem, hogy nem lehetne-e megoldani, hogy cgroup(ok) nélkül lehessen használni a TCP BPF-et, de azt mondta nagyon összenőve jött létre a kettő, nehéz lenne már szétszedni (szerintem nagy kár, hogy nem lehet adott alkalmazáshoz kötni például).

Később beültem a QUIC tutorialra, de aztán inkább átnéztem a wireless workshopra, hogy ott mikről van szó. Korábban olvastam egy PhD értekezésben airtime fairnesség témáról meg driver interfészről ehhez. A dolgozat írója is ott ült, meg persze pár nagyobb cég (Google, Intel, Atheros, Mediatek) wifi driver fejlesztője. Amikor beértem épp arról volt szó, miért szar a késleltetés wifi-n. Röviden: az airtime fairnesség miatt lassú, gyenge teljesítményen sugárzó eszközök ha sokan vannak rácsatlakozva egy AP-ra, elvehetik azoktól is az időt, akikkel nincs semmi gond. Ennek az egyik oka, hogy minden gyártó úgy implementálja a firmware-t meg a drivert, hogy azon belül még van pár saját scheduler queue. Ezzel nincs baj, viszont ezek néha túl nagyok, így hiába állítjuk be traffic controllal hogy CoDel limitálja a késleltetést pl. max 50 millisec-re, ez hatástalan lesz, mert a chipen késleltetődik nem ritkán fél másodpercet is. Azaz jön egy kliens, elindít pár TCP letöltést és neki mindenképp megnő a késleltetése, belassul a böngészés pl. de jó eséllyel a többiek is megszívják. A Google egyik mérnöke megmutatta, hogy ők mit csináltak: adtak egy interfészt a kernelnek, amivel minden csomaghoz megadható az előrejelzett airtime (a socket buffer control block nem használt részében). Ezzel dolgozik aztán a CoDel egy módosított változata (AQL-FQ-CoDel). Akit bővebben érdekel a megoldás itt olvashat utána: Airtime Based Queue Limit for FQ-CoDel

A Hardware Offload Workshopon folytattam ez után. Itt aztán volt minden, amiktől mostanában amúgy is hangos a net. Főleg a Mellanox mérnökei mutatták meg miket tudnak újabban de tényleg mindenki hozta a dolgait. XDP_DROP-os hardveres csomagdobás legújabban már 144 millió csomag/sec-nél jár. A SmartNIC-ek embedded switchéről is esett szó, ami lényegében egy programozható switch a virtuális és fizikai portok között. Szeretnék leváltani az SRIOV-t is ezzel (VF-ek helyett hardveresen gyorsított netdeviceok, a kártya 1 PCI eszközként látszik, dinamikusan jöhetnek létre, akár konténerenként is létrejöhet egy). Nagyon sok dolog volt sajnos nem sokra emlékszem ezekből. A lényeg, hogy lassan szinte minden offloadolva lesz, a VM-ek lineraten küldhetnek és fogadhatnak.

2. nap: Ismertették a TCP Prague motivációját és az implementációnak a részleteit. Ez a DCTCP congestion control egy módosított verziója, ami kis késleltetésű és kis veszteségű átvitelt próbál elérni. A DCTCP erre nem képes alapvetően mert olyan környezetre tervezték, ahol van end-to-end ECN és nem verseng más típusú congestion control algoritmusokkal. TCP Prague viszont a publikus interneten is működik, és vissza vesz ha más típusúakkal verseng. Bemutattak pár mérést, meg egy kis szimulátort is. A TCP Prague a legtöbb Qdisc mellett (persze legjobban a hozzá szabott DualPI2-vel) is képes volt Cubic szintű throughputra de nagyon kis sorbaállási késleltetéssel üzemelni (pár milliszekundum még nagy RTT-s esetekben is).

Beültem az XDP offload with virtio-net előadásra ez után. Hasonló dolgokról volt szó mint a HW offload workshopon, itt viszont konkrétan XDP-re kihegyezetten (ami ugye vendor független). Lényegében készülőben pár patchset virtio ökoszisztémához (virtio TUN/TAP + Qemu) ami a guestek hálózati sebességét képes konfiguráció nélkül, erre alkalmas kártyákon nagyjából a host sebességére feltornázni. Persze nem ennyire egyszerű a helyzet, sok dolgot meg kell még oldani, például ami elsőre eszébe jut mindenkinek, mennyire lesz az biztonságos, ha valaki guestből betölti a saját XDP programját, amit a host virtio drivere tovább ad a kártyának, ebben az XDP programban az eBPF kód meg közben eldobálja a többi VM forgalmát. Magyarán kell valami bővítése az eBPF verifiernek ami tekintetbe veszi, hogy a guest VM forgalmának offloadja nem akadályozza a host vagy a többi guest forgalmát.

Ez után a DualPI2 AQM implementációját mutatták be. Itt elég sok dolgot nem értettem, nem is próbálom meg összefoglalni, nehogy hülyeségeket írják. Ami nagyjából leesett belőle, hogy a TCP Prague miatt lett kifejlesztve és olyan helyeken jó, ahol skálázható CC (mint a DCTCP) mixelődik normál, nem ECN támogatott CC-kkel. Két queue-ja van, egyikbe megy a sima forgalom, a másikba meg a skálázható. Jó kérdés, hogy a classifier nem fogja-e vissza így a performanciát, hiszen válogatni kell a TCP flowokat. A trükk az, hogy nem lesz baj, mert elég az IP mezők alapján osztályozni, úgyis a lényeg, hogy az adott hostok forgalmaira nézve maradjunk fairek, azokon belül oldják meg ők az egyes flowok közti fair share-t.

Veth XDP: XDP for containers előadással folytattam, talán a legjobb előadás volt szerintem. A network namespace-k már jó ideje a kernel része, főleg konténereknél használják. Így lehet például sok konténerben ugyan az az IP cím anélkül hogy ütköznének. Namespacek között megoldhatjuk a kommunikációt mondjuk veth párokkal (https://blog.scottlowe.org/2013/09/04/introducing-linux-network-namespaces/). Ezzel az a baj, hogy bármennyire is gyorsak, CPU erőforrásba kerül a kommunikáció. Itt jön képbe a fenti előadásban bemutatott megoldás, ahol a már most is támogatott veth XDP generic driver kisebb módosításokkal offloadolhatóvá válik hálózati kártyákra. Ezzel nagyjából a fenti XDP-s virtio-hoz hasonlóan itt is elérhető lenne, hogy a konténerek közti (VM-knél egyébként olcsóbb) kommunikáció is teljes gyorsasággal menjen.

Ez után még pár XDP-s offloados téma, majd Hajime Tazaki előadása, ami arról szólt, különböző network stackek (van belőlük jó sok, pl. DPDK, Seastar, a Linuxé nyilván, LKL (ami szintén a linuxé de használható userspace libraryként). stb.) mennyi RFC-t támogatnak, mikor lehet és érdemes őket használni a Linux alap hálózati stackje helyett.

A konferencia fő szervezője Jamal Hadi Salim tartott előadást a TC u32 csomag osztályozóról, ami már nagyon régen része a linuxnak, nagyon gyorsan működik sok tízezer flowra is de a használata eléggé nehézkes ezért fontosnak tartotta elmagyarázni.

Ez után a Mellanox egyik mérnöke magyarázta, hogyan szeretnék egy új modellel megoldani az SRIOV live-migrationt. Egyes gyártók saját drivereikkel bizonyos konfigurációkkal ezt már támogatják, de ezek a törekvések arra irányulnak, hogy implementálva ezt a kernel interfészt minden gyártó kártyájával lehetőség legyen erre. Röviden annyi a megoldás (ezt sokkal bonyolultabb módon már csinálják egy ideje. MAC cím cserélős ügyeskedéssel) hogy van egy failover device, ami létrejön, ezt használja a VM, live-migrationkor ez fallbackel virtiora (ahol a live migration már nagyon régen jól megoldott) és a migration után az új hoston a failover device alatti interfész vált virtio-ról SRIOV VF-re. Rákérdeztem, hogy ezzel a modellel valahogy megoldható lenne-e RDMA-s forgalmú VM live migrationje, mondta, hogy az nem, de annyiban jobb, hogy konfiguráció nélkül ez a megoldás képes visszahozni az RDMA-s kapcsolatot, így ha a fölötte lévő alkalmazás fel van készítve a kapcsolat megszakadására, utána helyreállhat.

A napokban bemutattak két konténer kommunikációt gyorsító megoldást is, egyiket Usenix NSDI '19-en (SLIM) a másikat itt: AF_GRAFT. Mindkettő arra jó, hogy spóroljon pár layert a stacken amin nem kell keresztülhúzni feleslegesen a konténerek forgalmát. Cilium Kubernetesnél ezt az új 1.4 verziónál sockmap-el oldja meg (tavaly nyáron ezt én is használtam egy projekthez, remélem erről majd írhatok itt, sajnos egy kernel bug miatt még nem jól működik, erről majd később). Az AF_GRAFT egy új adress family, amihez a konténer socketet bindolva kihagyja az IP layert és a TCP socketek között közvetlenül teremti meg a kapcsolatot (kicsit sarkítva, de ez az alapelv).

Este találkoztam két Cloudflare-s mérnökkel, akik nemrég épp a sockmap-el foglalkoztak (https://blog.cloudflare.com/sockmap-tcp-splicing-of-the-future/), nagyon meglepődtek, hogy én vagyok az aki rajtuk meg az eredeti fejlesztőn kívül foglalkozott eddig vele. Beszélgetés közben egy szendviccsel a kezében (majdnem) elsétált mellettünk Tom Herbert, aki a kProxy RFC patchet küldte be (ami a sockmap őse még IOCTL interfésszel eBPF helyett és 1:1 socket mappinggel). Elpanaszoltuk neki a problémáinkat ő pedig nagyon segítőkészen sok jó tippet adott mivel lehetne javítani a teljesítményen meg a bugokon. Remélem sikerülni fog megjavítanom és egyszer majd egy netdev-en bemutatni összemérve az AF_GRAFT-al és a SLIM-el.

3. nap (röviden): a TCP BPF-hez kapcsolódva az MPTCP fő ötletgazdájának egy diplomamunkázó hallgatója mutatta meg, hogyan tervezik eBPF-el programozhatóvá tenni még jobban a TCP és az MPTCP (főleg annak a subflow kezelése) működését. Szerintem sok újdonság nem volt tartalmában a TCP BPF előadáshoz képest, igazából pár koncepcióból következő, nem túl fantáziadús módosítást mutattak be. IPsec over TCP előadás elég unalmas volt, ami miatt az implementáció mégis érdekes, az az, hogy (talán harmadikként a kernelben, a kTLS és a sockmap után) a streamparser infrastruktúrát használva oldották meg a TCP stack módosítása nélkül az IPsec parseolást. Szintén Mellanoxos előadás, arról, hogyan fogunk tudni kihajtani 200Gbps-t majd később 400-at és Tbps-t (egy kártyán persze). Nagyon közel vagyunk a technológiából adódó limitekhez, sok dolgot nem old meg az offload sem, okosan kell batchelni az adatokat, utasításokat és ügyesen kell szétszórni a magok között a NIC queue-ok feldolgozását. Ez után ismét TCP timestampingről, kicsit hosszabban, részletesebben. Ezek után főleg cégek mutatták be a saját megoldásaikat, nem volt marketingszagú a dolog, de nekem elég unalmasak voltak ezek az előadások. Volt szó access switchekről (házi és datacenter switchek közötti kategória kb.), konténerekről OpenWRT-n edge computinghoz, conntrack offloading Open vSwitch-hez, P4 compiler traffic controlhoz (ez elég érdekes mondjuk, de ahogy láttam főleg classifierekhez van), QUIC gyorsítás hálókártyán titkosítás és segmentetion offloaddal (személyesen nekem nem nagyon tetszik, hogy egy user-space protokolhoz próbálják reszelni már egész konkrétan a hardvert is, szerencsére nem voltam egyedül ezzel a véleménnyel). Ez után még egy XDP-s DDoS elhárítás, ahogy a Cloudflare-nél csinálják, majd egy záró előadás, statisztikákkal, szavazásokkal, stb. 234 résztvevővel kb. 33 országból ez a Prágai volt az eddigi legnagyobb Netdev konferencia. Sajnos nem tudom, voltak-e még Magyarországról, ennyire nem volt részletes a statisztika :-) Este még páran elmentünk sörözni random társaságokba ültem, elég érdekes sztorikat meséltek pl. Intel egyik wifi driver/firmware fejlesztője mesélte el első driver visszafejtését, 2005-ben hogyan találta ki a binárisból, hogy melyik milyen utasíts opkódja, milyen regisztereket használ és hogy melyik művelet hány regiszterrel dolgozik...

Konklúzió: Elég jó volt a konferencia, remélem egyszer elkészülök valamivel ami érdemes lehet ott bemutatásra. Akinek sok felesleges pénze van vagy fizeti a cég, annak ajánlom, sajnos minden évben más kontinensen rendezik, így én nem valószínű, hogy a legközelebbin részt fogok venni. Annak is ajánlom, aki hozzám hasonlóan nem konkrétan kernel programozásból él, de használja a legújabb hálózati technológiákat amiket a kernel nyújt vagy általában érdeklik a hálózatok.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Köszi a leírtakat! Ez jó lehetett.

Hát igen, valahol itt zajlik a jövő.
Nagy kár a melanox-ért, az nvidia semmi perc alatt szét fogja őket b@szni, most h. felvásárolta őket.
--

Én is nagyon kíváncsi vagyok mi a pontos tervük velük. Az intel is nagyon szerette volna megvenni őket, ha jól hallottam, gondolom senkinek nem jönne rosszul a Mellanox szabadalom portfóliója :-)

nem ertek egyet. miert csesznek szet? nekik pont hogy kell egy jol mukodo RoCE a GPU-to-GPU RDMA stackhez, nem erdekuk szetturni ezt.

ha jol ertem a felelmeket, az mellanox eddig halozat/IB teruleten tevekenykedett, az nvidia viszont a gpukat szeretne osszekotni, ehhez a mellanoxot belegyurja a gpu melle (es pl a "vga" kartyan lesz a link csatolo), az eddigi iranyt meg kukazza, mert neki nemkell halozat/IB.

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

valahova be kell dugni azokat a halokabaleket -> kellenek switchek, kellenek kartyak (hiszen max ugyanazt az ASIC-et tudja rarakni a GPUra, mint amit a NIC-re is rakna)

akkor ti nem feltek hogyha majd keves lesz a 200G a clusteretekhez, lesz majd 500G kartya?

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

szerintem nem titok hogy a 400Gbites kartyak "a kuszobon" vannak. hogy utana mi lesz, az a kerdes:)