Jaderné noviny – 15. 3. 2018: Odesílání paketů založené na čase

28. 3. 2018 | David Kolibáč | Jaderné noviny | 2517×

Stav vydání jádra. Novinky ve věci čistky architektur. Odesílání paketů založené na čase.

Stav vydání jádra

Kernel release status. Jonathan Corbet. 14. března 2018

Současné vývojové jádro je 4.16-rc5, vydané 11. března. Linus k němu řekl: „Nadále je to celkem v normě – tento kandidát na vydání je o něco větší než rc4, ale vypadá to na obvyklý výkyv daný načasováním žádostí o začlenění a ne nějaký stav nouze.“

Současný seznam regresí v cyklu 4.16 čítá devět známých problémů.

Stabilní aktualizace: 4.15.8 a 4.14.25 byly vydány 9. března. Následovaly je 11. března aktualizace 4.15.9, 4.14.26, 4.9.87, 4.4.121 a 3.18.99.

Další stabilní aktualizace 4.15.10 a 4.14.27 byly v době psaní tohoto článku revidovány a vyšly 15. března.

Novinky ve věci čistky architektur

An update on the architecture purge. Jonathan Corbet. 14. března 2018

V nedávném článku byla řeč o odstraňování starých, neoblíbených architektur z jádra. Od jeho napsání práce pokročily. Arnd Bergmann 14. března zaslal skupinu patchů, která odstraňuje dokonce osm architektur (blackfin, cris, frv, metag, m32r, mn10300, tile a score). Zdá se, že je předurčena do začleňovacího okna 4.17. Architektura unicore32, která byla už nějaký čas jednou nohou na popravišti, se dočkala záchrany, protože se přihlásil správce, který na ní bude dále pracovat.

Bergmann vypíchl opakující se vzorec mezi architekturami, které jsou kandidáty na vyřazení:

Nakonec se zdá, že ačkoliv se těch osm architektur mezi sebou dramaticky liší, všechny potkal stejný osud: Jediná firma se starala o produktovou řadu SoC, mikroarchitekturu CPU i softwarový ekosystém, což bylo nákladnější než si nechat licencovat novější generická jádra CPU třetí strany (typicky ARM, MIPS nebo RISC-V).

Když se započítá odstranění souvisejících ovladačů zařízení, celkem bude z jádra odebráno přes 450 tisíc řádek kódu. To naznačuje, že vydání 4.17 by klidně mohlo být menší, aspoň co do počtu řádek kódu, než 4.16 – bylo by to potřetí v historii jádra, že vydání by bylo menší než jeho předchůdce. Samozřejmě by takový milník mohl být zmařen přidáním dalších 100 tisíc řádek definic registrů GPU, ale vždycky můžeme doufat.

Odesílání paketů založené na čase

Time-based packet transmission. Jonathan Corbet. 8. března 2018

Když aplikace posílá data po síti, obvykle chce, aby byla přenesena co nejrychleji. Síťový kód v jádře se tomu snaží vyhovět. Jsou ale i aplikace, které potřebují, aby jejich pakety byly přeneseny v určitých časových oknech. Takovému chování se v současné době jde přiblížit na úrovni uživatelského prostoru, ovšem pracuje se na lepším řešení, které má podobu skupiny patchů odesílání paketů založeného na čase.

V řadě situací není žádoucí, aby odchozí data byla přenesena okamžitě. Příkladem budiž libovolný izochronní proud dat – řekněme zvukových nebo obrazových – ve kterém je každý datový paket aktuální právě v určitém okamžiku. V případě takových proudů odeslání předem a uložení do mezipaměti na straně příjemce obecně funguje docela dobře. Ale aplikace řízené v reálném čase nemusejí být tak flexibilní. Například příkazy pro výrobní linku nebo automobilový systém by měly být přeneseny v krátkém časovém úseku. Aplikace reálného času samozřejmě mohou počkat na otevření okna před seřazením dat k přenosu, ale jakákoliv latence, která se vkrade (například kvůli velkému zatížení sítě), může způsobit, že data budou přenesena příliš pozdě.

Komunita tvořící síťové standardy přirozeně pracuje na různých řešeních tohoto problému. Jedno z nich se nazývá P802.1Qbv. Jestli vám to přijde jako jazykolam, alternativní název je stručnější: „Standard for Local and Metropolitan Area Networks-Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks Amendment: Enhancements for Scheduled Traffic.“ Definuje mechanismus, kterým se vyprázdní fronty paketů tak, že každý paket je odeslán v daném termínu. Při použití P802.1Qbv mohou aplikace pakety řadit do fronty, kdykoliv jsou připravené, ale k odeslání nedojde, dokud se nepřiblíží příslušný termín.

Skupina patchů, která v Linuxu implementuje odesílání založené na čase, se skládá z několika oddělený částí. První přidává API, které aplikacím umožňuje, aby si dané chování vyžádaly. To se dělá tak, že se systémovým voláním setsockopt() nastaví nová volba SO_TXTIME. Pakety určené k načasovanému přenosu by se měly posílat pomocí sendmsg(), a to s hlavičkou řídící zprávy (typu SCM_TXTIME) obsahující závěrečný termín k přenosu v nanosekundách jako 64bitovou hodnotu.

Pomocí sendmsg() jde nastavit ještě pár dalších parametrů řídících zpráv. SCM_DROP_IF_LATE síťovému kódu říká, že má paket prostě zahodit, není-li z nějakého důvodu možné odeslat ho včas. Zpráva SCM_CLOCKID se hodí k určení, které hodiny se mají k časování paketů používat. Výchozí hodnota je CLOCK_MONOTONIC. Zdá se ale, že tento parametr se ve skutečnosti v současné implementaci nepoužívá – až na jednu malou výjimku popsanou níže.

Uvedené změny ústřední části síťového kódu umožňují nastavení chování založeného na čase, ale toto chování samotné neimplementují. To je věc doplňkové funkcionality. Jedna možnost, jak se k ní dostat, jsou pravidla řazení (queuing discipline) tbs, jež jsou také součástí skupiny patchů. Dají se nastavit, aby plánování založené na čase používala pro konkrétní frontu, a to s několika dalšími parametry. I zde lze určit ID hodin. Pokud se ID hodin objevuje také v jednotlivých paketech, musejí se obě ID shodovat, jinak budou pakety zahozeny. Další parametr, pojmenovaný delta, slouží k nastavení, jak dlouho před závěrečným termínem se mají jednotlivé pakety odesílat na síťové rozhraní k přenosu. Tento parametr a termíny jednotlivých paketů tedy určují okno, v němž by paket měl být poslán po drátě.

Pomocí delty a příznaku SCM_DROP_IF_LATE jde docílit dvou diametrálně odlišných druhů chování. Je-li příznak nastavený a delta přiměřeně velká, myslí se tím, že paket musí být vyslán na cestu před daným termínem. Naopak s malou (či nulovou) deltou a bez nastaveného příznaku SCM_DROP_IF_LATE je chování takové, že paket nebude odeslán, dokud termín nenastane.

Implementace pravidel řazení tbs sama o sobě spoléhá na „největší úsilí“ (best effort), jelikož stále existuje riziko, že pakety budou zpožděny poté, co je tbs vypustí na síťovém rozhraní. Skutečným záměrem P802.1Qbv je ale, zdá se, implementace přímo v síťových adaptérech. Je-li adaptér obeznámen s termíny k přenosu paketů, může si naplánovat přenosy, aby zajistil, že pakety vyrazí v patřičnou dobu.

Pravidla řazení tbs tudíž podporují přenesení (offloading) odesílání založeného na čase na hardware. Skupina patchů zahrnuje implementaci pro ovladač Ethernetu igb od Intelu. V případě úplného přenesení se namísto použití parametrů delta a ID hodin předpokládá, že všechny termíny jsou odvozené od interních hodin adaptéru a tím pádem adaptér zcela přebírá odpovědnost za načasování paketů. Pokud ale tyto parametry uvedeny jsou, tbs raději seřadí pakety a na začátku okna pro odesílání je pošle rozhraní, které i v tomto případě převezme odpovědnost za vyslání před uplynutím termínu. Jelikož tento režim používá jak jaderné hodiny, tak hodiny adaptéru, oboje musejí být synchronizovány, nebo se dostaví nežádané výsledky.

Skupina patchů je v současné době ve stádiu třetí revize. Původní verzi dodal Richard Cochran, ale nyní už se o to stará Jesús Sánchez-Palencia, který provedl řadu změn a přidal možnost přenesení odpovědnost na hardware. Zatím panují nějaké neshody o tom, jak by mělo fungovat API a především zda je opravdu potřeba mít možnost určit různé hodiny. Ukládání ID hodin v každém paketu totiž zvětšuje strukturu síťového kódu sk_buff, což je něco, čemu se vývojáři síťování už nějaký čas urputně brání. Bude trvat ještě aspoň jednu revizi, než se to vyřeší, takže není jasné, zda to tato skupina patchů stihne do začleňovacího okna 4.17.

       

Komentáře

[Jana J.]

Zdá se, že Mikrotik má problém, na procesorech Tile je založena jeho řada CCR...

[Ludvik]

Ani ne ... "RouterOS does not use any TILE code from the Linux kernel. This news has no effect on RouterOS."

[Jana J.]

Zajímavé, díky...

Mimochodem, pro zajímavost, při hledání podle první věty Google tu stránku nenajde. Nakonec pomohla Kachna...