Jaderné noviny - 7. 4. 2016: Brzké zahazování paketů a více s BPF

16. 4. 2016 | Redakce

Články - Jaderné noviny - 7. 4. 2016: Brzké zahazování paketů a více s BPF  

Stav vydání jádra. Citáty týdne. Brzké zahazování paketů – a více – s BPF.

Stav vydání jádra

Současný vývojový kernel je 4.6-rc2, vydaný 3. dubna. Linus řekl: „Všichni víte, co máte dělat – další týden, další rc. Vše zatím vypadá normálně, nejedná se o velké rc2, ale takhle to poslední dobou je (rc3 bývá větší – nejspíš protože lidem trvá, než si všimnou problémů).“

Stabilní aktualizace: Žádné nebyly od 16. března vydány.

Citát týdne

To *poslední*, o co stojíte, je programátor, který o sobě tvrdí, že je tak důležitý, že si zaslouží speciální futex. Protože každý programátor si myslí, že je výjimečný, a že _jejich_ kód je také výjimečný. Vím to, protože jsem výjimečný.

-Linus Torvalds

Citát týdne 2: Přistižen

Ne, nejsem Nick Krause. Jen si jsem vědom, jak byl před několika lety zabanován. Ten email byl omyl kvůli překlepu a já doufal, že se tím nikdo nebude zaobírat, protože by potom mohl uvěřit, že jsem Nick Krause.

-Bastien Philbert

Received: from [192.168.0.11]
        (CPEbc4dfb2691f3-CMbc4dfb2691f0.cpe.net.cable.rogers.com. [99.231.110.121])
        by smtp.gmail.com with ESMTPSA id w69sm1687054qhw.3.2016.04.06.10.23.24
    	(version=TLSv1/SSLv3 cipher=OTHER); Wed, 06 Apr 2016 10:23:25 -0700 (PDT)

-z hlavičky zprávy

 Received: from [192.168.0.11]
 	(CPEbc4dfb2691f3-CMbc4dfb2691f0.cpe.net.cable.rogers.com. [99.231.110.121])
	 by smtp.googlemail.com with ESMTPSA id o201sm11982708ioe.15.2016.02.22.12.12.53
	 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 22 Feb 2016 12:12:53 -0800 (PST)

-z dřívější Nickovy zprávy

Brzké zahazování paketů – a více – s BPF

Mechanismus Berkeley packet filter (BPF) se od roku 2014, kdy byl přepsán a rozšířen, pomalu dostává do různých subsystémů kernelu. Ukazuje se, že mít v kernelu virtuální stroj, který umožňuje implementaci libovolných pravidel bez nutnosti psát přímo jaderný kód, je velkým přínosem. Nedávný patch set, který protlačil BPF do síťových ovladačů, ukázal část potenciálu tohoto mechanismu – a také komplikace s návrhem integrace, která odolá zkoušce času. Bude-li úspěšný, může změnit způsob, jakým v Linuxu funguje velmi výkonné síťování.

Brzké zahazování

Tento patchset Brendena Blanca svým způsobem představuje návrat k původnímu účelu BPF: výběr paketů k přijetí nebo odmítnutí. V tomto případě dojde k výběru co možná nejdříve: přímo v ovladači síťového adaptéru, jakmile je paket přijat. Záměrem je, aby bylo nakládání s pakety co možná nejméně nákladné, pokud možno ještě před zpracováním protokolu, jako je zřízení struktury sk_buff (SKB) pro příslušné pakety.

Programy BPF mají při načtení systémovým voláním bfp() přiřazený typ, který je kontrolován, než dojde k načtení programu pro konkrétní úkol. Brendenův patch set začíná definicí nového typu (BPF_PROG_TYPE_PHYS_DEV) pro ty programy, které budou provádět brzké zpracování paketů. Každý typ programu obsahuje „kontext“ pro ty informace, které jsou dostupné, když program běží: v tomto případě musí kontext obsahovat informace o příslušném paketu. Interně je kontext reprezentován pomocí struct xdp_metadata, jež ve stávající verzi patch setu obsahuje pouze délku paketu.

Dalším krokem je přidání nové metody net_device_ops, kterou mohou ovladače poskytovat:

int (*ndo_bpf_set)(struct net_device *dev, int fd);

Volání ndo_bpf_set() řekne ovladači, aby nainstaloval program BPF označený poskytnutým deskriptorem souboru fd. Nový program by měl nahradit ten stávající, existuje-li takový. Záporná hodnota fd znamená, že jakýkoli existující program má být odstraněn. K dispozici je nová netlink operace, která uživatelskému prostoru umožňuje nastavit program na daném síťovém zařízení.

Ovladač může použít bpf_prog_get(), aby z deskriptoru souboru získal ukazatel na skutečný program BPF. Když přijde paket, makro BPF_PROG_RUN() může být použito ke použití programu na paket. Nenulová návratová hodnota programu říká, že paket by měl být zahozen.

Jen začátek

Spory začínají hned u rozhraní pro běh programu BPF. Ovladač jistě musí spouštěnému programu poskytnout informace o novém paketu. To se děje předáním ukazatele na SKB makru BPF_PROG_RUN(). Vnitřní mechanismy skryjí předané SKB vznik informace xdp_metadata. Působí to dostatečně přímočaře, navíc se využívá výhod existující funkcionality BPF pro práci s SKB. Je tu však několik námitek. První z nich je, že smyslem mechanismu pro brzké zahazování je vyhnout se režii zpracování paketů, které by stejně byly zahozeny. Jenže vytvoření SKB už je počátečním a nezanedbatelným podílem režie. Vytvářet ji za všech okolností se tak jeví kontraproduktivní.

Ve skutečnosti ovladač (mlx4), který byl modifikován k implementaci tohoto mechanismu, nevytváří plnohodnotnou SKB. Místo toho vkládá minimum informací do falešné, statisticky alokované SKB. Tím se vyhýbá režii, ale za cenu vytvoření SKB, která ve skutečnosti není SKB. Množství informací, které musí jít do falešné SKB, se nepochybně bude časem zvětšovat – poptávka po možnosti zahazovat pakety pouze na základě jejich délky je překvapivě malá. Kdykoli bude zapotřebí nový typ informace, bude nutné upravit každý ovladač tak, aby ji poskytl, takže časem bude výsledek vypadat jako skutečná SKB s odpovídající režií.

Dalším problémem je, že panuje docela velký zájem o to, aby se programy BPF (možná po překladu) nakonec dostaly až do síťového adaptéru samotného. To by umožnilo zahazovat pakety dříve, než by si jich všiml kernel, čímž by došlo k další optimalizaci procesu. Tento hardware ovšem nebude nic vědět o struktuře SKB. Uvidí jen to, co bude přímo v paketu. Jsou-li programy BPF psány tak, aby očekávaly SKB, nebudou fungovat po začlenění do hardwaru.

Je zde ovšem ještě větší problém: rychlé zahazování paketů je užitečná věc, ale uživatelé velmi výkonného síťování chtějí mít možnost dělat víc než to. Rádi by možnost načítat programy BPF pro rychlé směrování, přepis obsah paketů v čase přístupu, odstranění zapouzdření, spojování velkých paketů atd. Pro „expresní datové cesty“ (nebo XDP) existuje celá vize, postavená kolem nízkoúrovňového zpracování paketů pomocí BPF, viz tuto prezentaci [PDF] pro přehled o tom, co mají vývojáři na mysli. Stručně řečeno, chtějí poskytovat ten typ optimalizovaného procesního výkonu, který láká uživatele k použití síťové vrstvy uživatelského prostoru při zachování toho, co je v jádře, a veškeré související funkcionality.

Jestliže bude třeba rozšířit mechanismus nad rámec rozhodnutí přijmout/zahodit, bude se muset zvětšit objem informací a funkcionalita dostupná programům BPF, nejlépe bez poškození již existujících uživatelů. Jak řekl Alexej Starovoitov: „Musíme naplánovat celý projekt tak, abychom mohli postupně přidávat nové funkce, aniž by bylo třeba rozbít ABI.“ Současný patch set ovšem nereflektuje takový způsob plánování, místo toho se jedná o vyslání žádosti o připomínky k zavedením mechanismu, na kterém chtějí XDP vývojáři stavět.

Takže je jisté, že tento kód se do hlavního repozitáře v současné podobě nedostane. Ale dosáhl požadovaného účinku, kterým bylo rozproudění konverzace, a zdá se, že o zavedení takové funkcionality je opravdu zájem. Jestliže bude přístup XDP schopen dosáhnout svých cílů ohledně výkonu a funkcionality, mělo by to uživatelskému prostoru stát za to. Ale než se do té fáze dostaneme, bude třeba udělat spoustu práce.

Diskuse k tomuto článku