Jaderné noviny – 16. 8. 2012: Rychlejší lokální TCP

3. 9. 2012 | Luboš Doležel | Jaderné noviny | 3536×

Aktuální verze jádra: 3.6-rc1. Citáty týdne: Neil Brown, Matthew Garrett. Pracovní fronty, které nejsou reentrantní. Přátelé v TCP. Načítání firmwaru a suspend/resume.

Obsah

• Aktuální verze jádra: 3.6-rc1
• Citáty týdne: Neil Brown, Matthew Garrett
• Pracovní fronty, které nejsou reentrantní
• Přátelé v TCP
• Načítání firmwaru a suspend/resume

Aktuální verze jádra: 3.6-rc1

Aktuální vývojová verze je nadále 3.6-rc1; Linus další předverzi nevydal, protože byl od 2. srpna na dovolené. Do repozitáře se ale postupně dostávají opravy; další verze by měla vyjít brzy.

Stabilní aktualizace: verze 3.0.40, 3.4.8 a 3.5.1 vyšly 9. srpna; verze 3.2.27 vyšla 11. srpna; a verze 3.0.41, 3.4.9 a 3.5.2 vyšly 15. srpna. Poslední zmiňovaná skupina obsahovala kromě běžných oprav i vylepšení v generátoru náhodných čísel.

Citáty týdne: Neil Brown, Matthew Garrett

Snažím se předstírat, že jsem neschopný správce, aby se někdo nabídl, že to po mě převezme. Zatím to nevyšlo.

-- Neil Brown

Nuže, tohle byla má snaha strávit několik dnů nad něčím pohodovějším než secure boot. Skončilo to ekzémem a bolestí jater. Plyne z toho pro mě ponaučení, že výrobci hardwaru vás nenávidí ještě víc než výrobci firmwaru.

-- Matthew Garrett

Pracovní fronty, které nejsou reentrantní

Pracovní fronty jsou hlavním nástrojem pro odklad úloh v linuxovém jádře. Správcem této funkčnosti je Tejun Heo, který nedávno zaslal sadu patchů měnící vlastnost pracovních front, o které ví asi jen málo jaderných vývojářů. Většina pracovních front je reentrantní, což znamená, že stejná položka ve frontě může běžet na více CPU současně. To může vést k souběhu, jenž nemusí vývojáři očekávat; taktéž to zajímavým způsobem dosti komplikuje různé „flush“ operace. Tejun to shrnuje slovy:

Pracovní fronty jsou ve výsledku dost nepříjemné, je obtížné udělat věci správně a stejně tak obtížné je postřehnout, že se něco rozbilo. Podle situace, jak se úlohy zrovna řadí do fronty, může předpoklad, že fronta není reentrantní, být po většinu času v pořádku. Dopad používání flush_work() namísto správného flush_work_sync() může být ještě méně nápadný. To, že by se flush_work() stalo nulovou operací, se stane jen naprosto výjimečně, ale určitě to hrozí.

Nástroj, které je tak intenzivně používán, jako jsou pracovní fronty, by neměl být tak složitý a náchylný na chyby. To je prostě hloupé.

Tejunův patch má za cíl změnit rozhraní front tak, aby se chovalo více jako rozhraní časovače, které je v souběhu opatrnější. Zjevně to má za následek drobné snížení výkonu, ale Tejun je označuje za zanedbatelné a měly by se urychlit operace flush. Vypadá to, že to za to stojí, ale všichni, kteří udržují kód závisející na souběžném spouštění úloh ve frontě, by měli být na pozoru.

Přátelé v TCP

Jednou z mnoha výhod síťového protokolu TCP je to, že procesy na obou stranách nemusejí mít tušení, kde se druhá strana nachází. Proces může komunikovat s procesem na druhé straně světa, ve stejném městě nebo samozřejmě na stejném stroji. Poslední situace nemusí být relevantní pro zmiňované procesy, ale může být důležitá pro uživatele citlivé na výkon. Nový patch od Google tuto situaci v brzké době zrychlí.

Buffer dat zaslaný sítí necestuje sám. Vrstva TCP musí buffer rozdělit do rozumně velkých paketů, připojit sadu hlaviček TCP a pravděpodobně i spočítat kontrolní součet. Pakety jsou pak předány vrstvě IP, která přidá vlastní hlavičky na začátek bufferu, najde vhodné síťové rozhraní a předá výsledek tomuto rozhraní k odeslání. Na druhé straně tento proces probíhá opačně: hlavičky IP a TCP jsou odstraněny, kontrolní součty jsou porovnány a data jsou sloučena do souvislého proudu.

Jde o docela dost práce, ale umožňuje to dvěma procesům komunikovat nezávisle na tom, co se děje mezi nimi. Ale pokud jsou oba procesy na stejném stroji, většina této práce není skutečně nutná. Většina režie v síťové vrstvě souvisí se snahou zabránit ztrátě dat po cestě. Toto nehrozí v případě, že data systém vůbec neopouštějí, takže spousta práce síťové vrstvy je zcela zbytečná.

To vývojáři vědí už celé roky. Proto tolik programů umí používat unixové sokety při komunikaci s místními procesy. Unixové sokety poskytují stejnou úroveň abstrakce, ale protože nekomunikují mezi systémy, vyhnou se tak režii přidávané plným síťovým stackem. Rychlá komunikace mezi procesy tedy možná je, ale musí se s ní počítat explicitně.

Co kdyby komunikaci přes TCP bylo možné zrychlit tak, aby byla srovnatelná s unixovými sokety? To je cílem tohoto patche od Bruce Curtise. Myšlenka je prostá: když jsou oba konce spojení na stejném stroji, sokety jsou v jádře označeny jako „spřátelené“. Data zapsaná do takového soketu budou okamžitě zařazena pro čtení na druhém soketu, takže se síťové vrstvě vyhnou. Vrstvy TCP, IP a loopback se tím obejdou. Samotný patch je pak pochopitelně trochu složitější než co by dal tušit samotný popis; spřátelené sokety se musejí nadále chovat jako TCP sokety do míry, aby aplikace nic nepoznaly, takže ošetřování přátel musí být řešeno na mnoha místech ve vrstvě TCP.

Člověk by doufal, že výsledkem budou rychlosti alespoň blízké unixovým soketům. Brucův patch toho nejen dosahuje, ale unixové sokety dokonce předčil v téměř všech testech. „Předčil“ znamená vyšší rychlost přenosu i nižší latenci. Bruce už nerozebírá, jak je to možné; třeba za to může úsilí vložené do škálovatelnosti síťové vrstvy ve spojení se 16jádrovým systémem.

Zbývá jeden test, který Bruce nedělal: nezpomaluje náhodou jeho patch komunikaci se vzdálenými stroji, kde není obcházení síťových vrstev možné? Některá vytěžovaná místa mohou být citlivá i na ty nejmenší změny, takže se dá čekat, že vývojáři budou chtít ujištění, že vzdálená spojení neutrpí. Zbývají ještě další drobné problémy, jež je nutné vyřešit, ale vypadá to, že se patch dostane do jádra v brzké budoucnosti.

Po začlenění by výsledkem byla rychlejší lokální komunikace mezi procesy bez nutnosti dodatečného kódu pro unixové sokety. Mohlo by se to hodit i k rychlejší komunikaci mezi kontejnery; dá se odhadovat, že tak nějak je to používané i v Google. Tak jako tak je těžké bojovat proti patchi, který dokáže až pětinásobně urychlit lokální komunikaci, tudíž je pravděpodobné, že se patch dostane do jádra velmi brzy.

Načítání firmwaru a suspend/resume

Mnoho zařízení nedokáže fungovat, dokud do nich systém nenačte ten správný firmware. Firmware načítaný za běhu má své výhody: hardware může být levnější vyrobit a firmware je možné snadno aktualizovat i po prodeji výrobku. Představuje to ale i problémy, zejména ve spojení s jinými funkcemi. Správné načítání firmwaru při cyklech suspend/resume představovalo pro jádro už nějakou dobu velkou výzvu, nová sada patchů by to ale měla zlepšit bez potřeby změn v ovladačích.

Problémem je zjevně to, že kterékoliv zařízení může během uspání ztratit svůj firmware. Smyslem uspávání systému je snížení spotřeby na minimum, takže některé periferie se mohou vypnout úplně. Ztráta firmwaru při uspání nevypadá jako velký problém; ovladač přece může firmware při probouzení systému načíst znovu. Jenže firmware se nachází na disku a k jeho načítání je nutné spustit pomocný proces v uživatelském prostoru. Disk a uživatelský prostor nemusejí být v době, kdy si zařízení vyžádá firmware, dostupné; ovladače, které se o to pokusí, mohou škaredě selhat. Výsledkem jsou pak selhání probuzení systému; mohou být náhodná, takže na ně vývojář nikdy nenarazí a nikdy je ani nevystopuje. Proto se už nějakou dobu hledá robustnější řešení.

Ming Lei se v červenci pokusil tento problém vyřešit patchem, který integruje načítání firmwaru do mechanismu odloženého zkoušení ovladačů. Zjednodušeně jde o to, že pokud načtení firmwaru selže, tak je celá inicializace ovladače odložena do fronty, odkud je pak pokus opakován. Tudíž pokud ovladač nebude schopen načíst svůj firmware během probouzení, zkusí se to později znovu a tehdy už snad budou potřebné prostředky dostupné. Ming doufal, že to vyřeší mnoho selhání probuzení bez potřeby měnit spousty ovladačů.

Linus ale nesouhlasil:

U spousty zařízení nevadí načíst firmware později. Některá ale mohou být kritickou součástí sekvence probuzení systému a odložení načtení firmwaru tak bude jen znamenat selhání probuzení.

Podobný způsob odložení načtení firmwaru by dle jeho názoru ukryl problémy před vývojáři a poprali by se pak s nimi uživatelé. Je prý mnohem lepší donutit autory ovladačů řešit problém explicitně.

Tradičním způsobem řešení problému je udržovat firmware v paměti po jeho načtení. Trvale načtený firmware bude vždy k dispozici, takže opětovné nahrávání by mělo být robustní. Problémem je, že některý firmware může být dosti velký; trvalé udržování by plýtvalo jadernou pamětí. A je to ještě horší, bloby jsou načítané do paměti vmalloc() (aby byly v paměti souvislé); této paměti může být na 32bitových systémech málo. Trvalé cachování tedy není ideálním řešením, ale tak to hodně ovladačů teď dělá.

Po debatě s Linusem se Ming na chvíli zamyslel a přišel s novým návrhem: firmware cachovat, ale jen během cyklu suspend/resume. Ovladače to samozřejmě mohou takto dělat už teď. Ale jde o spoustu opakujícího se kódu, který by bylo nutné přidat do každého ovladače. Mingův patch tyto kroky automatizuje a zjednodušuje.

request_firmware() je konkrétně změněno tak, aby si zapamatovalo název každého načítaného blobu. K tomuto je uložen počet referencí a údaj o tom, která zařízení firmware potřebovala; při odpojení pak tedy celý záznam může být odstraněn. Výsledkem je jednoduchá datová struktura sledující všechny bloby, které mohou být požadovány hardwarem, jež je v systému aktuálně přítomen.

Při uspávání pak kód jednoduše načte všechen firmware, o kterém věří, že může být potřeba. Tato data následně zůstávají v paměti během uspání. Při probouzení systému jsou takto nacachované bloby dostupné ovladačům bez potřeby přístupu k souborovému systému nebo uživatelskému prostoru přes obvyklé rozhraní request_firmware(). Jakmile je proces probuzení dokončen, načítač firmware veškeré obrazy firmwaru uvolní.

Patch má zdá se k ideálnímu řešení blízko. Načítání firmwaru při probouzení se stane robustnějším, ovladače se o princip fungování nemusejí starat a promrhané paměti je minimum. I Linus poznamenal Nic mě na tom patchi nezhnusilo, což je od něj docela vysoké ocenění. Neřeší to ale každý problém; kupříkladu pak existují podivná zařízení, která si firmware uchovají během restartu, ale už ne během uspání, takže systém nemusí o potřebě firmwaru tušit a pak už je pozdě. Takový hardware je ale asi lepší řešit odděleně jako speciální případ. Pro zbytek se blížíme řešení, které prostě funguje – a tím se přibližujeme ke konci věčných debat na téma „firmware po probuzení“.

       

Komentáře

[jarda]

Prvy! Kdyz vam to minule chybelo

[Max]

Nechovej se jak malej Jarda.
Zdar Max

[Jardík]

Jardík!!!!

[Pev]

Druhý citát vložil Matthew Garrett (thanks to Cesar Eduardo Barros) a vede na http://mjg59.dreamwidth.org/15948.html.

[Luboš Doležel (Doli)]

Díky.

[pc2005]

For example, maybe it's a USB network dongle, and for *YOU* it is perfectly fine to defer the firmware loading, so that the network comes back up a few seconds after the system is up and running.

But in another machine, that exact same USB network dongle may actually be hardwired on the motherboard (it's fairly common to use USB as a "system bus" in some laptop and embedded devices), and maybe that other machine actually is a thin client that has some tiny rdinit thing, and then everything else is NFS-mounted, and if you resume without networking, the machine is simply *dead*.

Pokud má tenkej klient nějaký úložný místo odkud bootuje z rdinit, tak tam musí mít i firmware, aby mohl připojit NFS ne? V nejhorším případě je ten firmware v BIOSu, ale aspoň je furt dostupnej.

[R]

initrd moze byt stiahnuty cez PXE pocas bootovania. Firmware moze byt v BIOSe, ale to neznamena, ze je kompatibilny s linuxovym driverom a ze po zobudeni bude nahraty v sietovke (ked nebude, tak ho z BIOSu len tak nevytiahnes).

[pc2005]

Z BIOSu by to jít mohlo i když by to byla tuna práce skoro nanic. Problém je s touhle BIOS variantou imho hlavně to, že koncept: spoléhám na firmware z BIOSu je dost slabej (leda by ho po PXE bootu kernel přepsal znova, ale to se mi moc nezdá). Lepší by bylo pro tenhle případ vytvořit ramdisk.

[R]

A namiesto takychto odpornych hackov, ktore by bolo potrebne robit pri kazdom HW samostatne, je tu to elegantne riesenie s cachovanim firmware pred uspanim.

[pc2005]

Kolik je vlastně zařízení, které mají firmware v BIOSu? V .probe driver většinou detekuje, že je firmware obsazený a už načítat nebude (load_firmware funkce se pak úplně přeskakují). Doufám, že ten návrh s tím počítá a někde si zjistí kompatibilní soubor s firmwarem. Přičemž během vykonávání .suspend driveru už může být IMHO pozdě, protože: Usb wifi driver chce načíst firmware do cache ze sítě, ale usb2ethernet už spí. Co když je občas stroj připojenej přes usb wifi a chce uložit firmware usb2ethernet? To by ten návrh musel řadit volání .suspend a to se mě nezdá (četl jsem jen velmi zběžně kousky kódu z delších patchů, co autor poslal).

BTW Nevíte někdo jakej hardware potřebuje mít firmware fyzicky spojitě v libovolné lokaci v RAM? Pokud se uploaduje firmware přes jeden registr, tak mě stačí ho číst ve smyčce ze stránkovaného bufferu nebo použít scatter-gather DMA. Pokud vyžaduje oblast v MMIO, tak víceméně taky. Mě napadá jenom něco jako SoC s ARMem a DSP, ale tam ten firmware stejně zůstává v obecné RAM.

Kdybych měl od bootu ramdisk v /lib/firmware, tak mám všechny soubory firmwarů lehko přístupné z userspace a mohu s nimi operovat. Load_firmware by potom jenom znova načetl firmware z filesystému. Jediný problém oproti cachování by byl, že v nejhorším případě by to potřebovalo sum(firmware_length)+max(firmware_length) oproti sum(firmware_length) u cache verze. Ale zase by všechny firmware mohly být stránkované, kromě max(firmware_length) a to jen ze zařízení, které potřebují souvislý blob.

No když si to po sobě čtu, tak je asi ten navrhovaný patch dostatečný (už jen proto, že měl autor chuť to naprogramovat ). Mě hlavně vadilo, že bude v kernelu další systém co bude automaticky hejbat operační pamětí.

[Franta]

Data zapsaná do takového soketu budou okamžitě zařazena pro čtení na druhém soketu, takže se síťové vrstvě vyhnou.

A co iptables pravidla, která by se měla aplikovat? Pokud potřebuji přímé spojení, tak přece použiji unixové sockety -- a to má i jiné výhody (řízení přístupu podle uživatelů). Tu abstrakci by měla řešit spíš nějaká knihovna/framework v aplikaci, než že by OS měl dělat takovéhle hacky, podstrkávat nějaké přímé spojení a tvářit se, že je to TCP.

[pavlix]

A co iptables pravidla, která by se měla aplikovat? Pokud potřebuji přímé spojení, tak přece použiji unixové sockety

Taky se divím, proč se řeší věc, která už je vyřešená, ale budiž, nejspíš to bude nějaká specifická potřeba Googlu.

[Jindřich Makovička]

Navázání a ukončení spojení jde pořád skrz kompletní TCP stack, takže ve většině případů použití iptables to vadit nebude.

Navíc se tenhle hack dá vypnout.

[Franta]

A co filtry, které se aplikují na jednotlivé pakety?

Že to jde vypnout, je sice hezké, ale IMHO to tam nemá být vůbec. Čisté řešení je abstrakce na nějaké vrstvě mezi aplikací (resp. jejím jádrem) a OS, která umožní používat TCP, UNIXové sokety (případně STDIO, nějaké tunelované věci, sériovou linku, zvláštní HW atd.) stejným způsobem. Pokud není možné upravit aplikaci a přidat do ní tuhle vrstvu, mělo by to jít udělat přes LD_PRELOAD.

[kuka]

Prave ze aplikaci je uplne jedno, zda a jaka pravidla se cestou na jeji komunikaci aplikuji. Pro ni je to transparentni a ze nekdo komunikaci optimalizuje ji nijak neposkodi. Pokud na neco potrebuju lokalne aplikovat filtrovani paketu, tak si optimalizaci vypnu/nezapnu, to je otazka pro spravce. Zapracovat do kazde aplikace jakousi abstrakci na toto tema je mozna svym zpusobem cistsi, ale plosne nerealne a zbytecne - vetsina uzivatelu nema a nikdy nebude mit s rezii TCP zadny problem, to zacina byt zajimave pocitam tak od tisicu soucasne komunikujicich procesu.

[j]

On vetsinou spravce predpoklada, ze pokud neco komunikuje po siti, tak to komunikuje po siti a ne nejakou dirou nekde cestou. Aby jeste resil, kde co povypinat a kde co pozapinat, aby to vazne komunikovalo tak, jak potrebuje ... nehlede na to, ze admin v principu vubec nemusi tusit, ze nekdo pouziva nejaky aplikace komunikujici pres sitovy rozhrani, admin vetsinou nastavuje nejaka globalni pravidla ...

[Franta]

Tak nějak... Obecně nic proti optimalizaci, ta je žádoucí, jen to nesmí být za cenu rozbití jiných věcí nebo zanesení děr do systému.

[pavlix]

On vetsinou spravce predpoklada, ze pokud neco komunikuje po siti, tak to komunikuje po siti a ne nejakou dirou nekde cestou.

Oni jsou ti správci vůbec často překvapení, co se to v jejich sítích děje. A to kolikrát i když si to sami nakonfigurovali. Ale souhlasím s tebou a je mi osobně proti srsti jim v tom dělat ještě větší bordel, než je nutné.

Až budu testovat aplikaci na localhostu a sledovat si ji tcpdumpem a ten tcpdump mi bude ty pakety zatajovat, tak se mi to nebude líbít. Už teď musí člověk lokální komunikaci hledat na rozhraní lo místo rozhraní, na kterém je daná IP nastavená.

[Ondrej 'SanTiago' Zajicek]

Už teď musí člověk lokální komunikaci hledat na rozhraní lo místo rozhraní, na kterém je daná IP nastavená.

To je ovsem perfektne konzistentni s chovanim IP komunikacie v Linuxu obecne - pokud napr. prichazi komunikace na eth0, ale je cilena na IP z eth1, tak ji na eth1 take tcpdumpem nezachytim. Ono na Linuxu je to prirazeni IP rozhranim relativne volna a neprilis dulezita vazba, napr. na ARP ti odpovida bez ohledu na to, na kterem to rozhrani ta adresa je.

[pavlix]

To je ovsem perfektne konzistentni s chovanim IP komunikacie v Linuxu obecne

To vůbec nerozporuju :).

napr. na ARP ti odpovida bez ohledu na to

Mně lokální stroj na ARP neodpovídá nikdy. Vzdálený stroj mi správně na ARP odpovídá pouze pokud použiju jeho adresu na rozhraní, po kterém ten ARP dostane.

[Ondrej 'SanTiago' Zajicek]

Vzdálený stroj mi správně na ARP odpovídá pouze pokud použiju jeho adresu na rozhraní, po kterém ten ARP dostane.

Tak to ho mas prenastaven nebo prislusne zafirewallovan. Defaultni chovani je takove, jake pisu.

[Cronin]

On vetsinou spravce predpoklada, ze pokud neco komunikuje po siti, tak to komunikuje po siti a ne nejakou dirou nekde cestou.

Správca má vedieť, nie predpokladať. Správca, ktorý mal už pod rukami taký Solaris, nič také predpokladať nebude. Tam totiž localhost odjakživa funguje predávaním údajov v pamäti.

[Michal Kubeček]

Tak samozřejmě funguje i na Linuxu. Rozdíl je jen v tom, že s tímto patchem se nebudou v paměti předávat celé sestavené (IP) pakety, ale rovnou příslušné segmenty aplikačního streamu.

[Michal Vyskočil]

Spíš přemýšlím, kde jinde, než v paměti, by se taková komunikace měla vlastně odehrávat. Nemyslím, že by někdo chtěl psát (de)serializaci z/do souboru

[Michal Kubeček]

Taky pravda… Na druhou stranu, zrovna včera jsem při řešení jednoho bugu ke svému překvapení zjistil, že i když se to celé předává jen v paměti, stejně se na to kopírování za určitých okolností může používat DMA, takže jeden nikdy neví…

[Ondrej 'SanTiago' Zajicek]

Predstava takove abstrakce me prijde dost absurdni. Ne ze by to neslo (pokud by se kvuli tomu prekopala pulka aplikaci), ale bud by to byla nejaka hyperobecna abstrakce, s kterou interfacovat by bylo obecne tezke kvuli ruznorodosti navazujici infrastruktury, nebo by to proste emulovalo TCP pomoci UNIX socketu (kdyz by klient resolvoval DNS a zjistil, ze cil je na stejnem stroji, tak by misto TCP spojeni zkusil otevrit UNIX socket napr. na /tmp/pseudotcp/port80), pak by to bylo relativne jednoduche (alespon na strane klienta), ale ten problem, ktery resi zmineny patch, by i tak vyzadoval radove vic prace, a vzniklo by tam spousta zcela zbytecnych potizi.

Predstava, ze by se takova abstrakce narvala do stavajicich aplikaci pomoci LD_PRELOAD, je jeste absurdnejsi (napr. situace kdy mam TCP server poslouchajici na jednom socketu, ted by musel poslouchat na dvou - pro TCP a pro UNIX sockety).

[Franta]

Taková abstrakce je např. v Javě - nakonec z toho máš vstupní/výstupní proud, co je pod tím, řešit nemusíš, může tam být X proxy, obalů, kompresí, šifrování, kódování... a někde úplně pod tím je ten unixový soket, TCP spojení, soubor, vstup/výstup jiného procesu atd.

[pavlix]

Abstrakce, o jaké mluvíš je řešena už na úrovni kernelu. Socket je prostě file descriptor, ať už unixový nebo TCP/IP, stejně jako soubor a další.

[Ondrej 'SanTiago' Zajicek]

To je ale dost odlisny pripad. Zatimco u fd sice programator pouziva stejne funkce, tak ale typicky vi a pocita s tim, ze pouziva fd nejake 'tridy' a pulka operaci je specificka ci se chova lehce jinak pro jednotlive 'tridy', tak puvodni prispevek (jak jsem ho pochopil) pocital s tim, ze by ta abstrakce byla v podstate transparentni pro programatora (takze by abstraktni vrstva klidne vymenila pri lokalni komunikaci TCP za unix socket a program by si toho nevsiml).

[pavlix]

To je ale dost odlisny pripad. Zatimco u fd sice programator pouziva stejne funkce, tak ale typicky vi a pocita s tim, ze pouziva fd nejake 'tridy' a pulka operaci je specificka ci se chova lehce jinak pro jednotlive 'tridy'

Zajímalo, jak se pozná ta specifická půlka operací v době, kdy už jsem připojený (či je někdo ke mě připojený) pomocí TCP nebo pomocí UNIX/STREAM.

V tu dobu používám read/write (mohl bych používat send/recv) a časem asi budu chtít použít close. To celé doprovází poll u asynchronního přístupu. Víc mě nic nenapadá.

takze by abstraktni vrstva klidne vymenila pri lokalni komunikaci TCP za unix socket a program by si toho nevsiml

Což dělá víceméně ten kernel patch. Vymění TCP protokol za jednodušší způsob lokálního předávání dat po vzoru AF_LOCAL.

[Ondrej 'SanTiago' Zajicek]

Tak treba ve funkcich pracujicich s adresami (getsockname(), getpeername()), ty se obcas pouzivaji pote, co se na listening socket nekdo pripoji.

Pak spousta socket options nastavovanych pres setsockopt(), s pouzivanych treba TCP_CORK, IP_TOS, IP_TTL.

Samozrejme, to je porad ten nejpodobnejsi pripad, treba takove datagramove sockety (napr. UDP a RAW sockety) se lisi v daleko vic vecech.

Což dělá víceméně ten kernel patch. Vymění TCP protokol za jednodušší způsob lokálního předávání dat po vzoru AF_LOCAL.

Jenze ten patch taky (hadam) zajistuje, aby se pro vsechny ty 'trida-dependent' operace stale choval jako TCP. Zatimco u nejake typicke genericke abstrakce kdybych chtel precist cislo portu ze socketu, ktery je vlastne implementovan unix socketem, tak by to selhalo.

[pavlix]

Tak treba ve funkcich pracujicich s adresami (getsockname(), getpeername()), ty se obcas pouzivaji pote, co se na listening socket nekdo pripoji.

Proto jsou adresy polymorfní.

Pak spousta socket options nastavovanych pres setsockopt(), s pouzivanych treba TCP_CORK, IP_TOS, IP_TTL.

Ještě jsem nepotřeboval nastavovat volby jindy než během inicializace.

Jenze ten patch taky (hadam) zajistuje, aby se pro vsechny ty 'trida-dependent' operace stale choval jako TCP.

Pokud používám přímo socketové rozhraní a jeho úroveň abstrakce, tak někde v kódu volám socket(), kde určuju, jaký typ socketu to bude. V návaznosti na to lze vyřešit všechny specifické věci. Na straně serveru to bude accept().

Zatimco u nejake typicke genericke abstrakce kdybych chtel precist cislo portu ze socketu, ktery je vlastne implementovan unix socketem, tak by to selhalo.

U generické abstrakce je nesmysl číst číslo portu. Stejně tak u polymorfního socket API nemá smysl chtít číslo portu od AF_LOCAL.

[Ondrej 'SanTiago' Zajicek]

Proto jsou adresy polymorfní.

Jo, jenze v konecnem dusledku tu adresu stejne budes chtit nejak zpracovat a tam uz jde polymorfnost stranou (nehlede na to, ze pro ni predem musis vyhradit dost pameti).

U generické abstrakce je nesmysl číst číslo portu. Stejně tak u polymorfního socket API nemá smysl chtít číslo portu od AF_LOCAL.

Pokud by ta abstrakce byla 'natolik' polymorfni, aby podstrcila UNIX socket tam, kde programator zadal TCP, jen na zaklade toho, ze IP adresa cile je lokalni (jak IMHO pozadoval puvodni prispevek), tak by mysela byt natolik transparentni i v ostatnim 'trida-dependent' chovani.

[pavlix]

Jo, jenze v konecnem dusledku tu adresu stejne budes chtit nejak zpracovat a tam uz jde polymorfnost stranou

Tam přesně využiju polymorfie, která mi mimojiné nabízí možnost větvit kód podle konkrétního podtypu.

Pokud by ta abstrakce byla 'natolik' polymorfni, aby podstrcila UNIX socket tam, kde programator zadal TCP

Taková abstrakce mi přijde na první pohled chybná. Správná abstrakce je taková, která dokumentované rozhraní implementuje. V tomto případě musíš buď změnit abstrakci, aby si poradila se všemi specifiky TCP (což se skoro určitě lépe udělá v kernelu a což dělá zmíněný patch), nebo musíš změnit dokumentaci, tedy poskytované API a nevydávat AF_UNIX za AF_INET*, ale udělat smysluplnou abstrakci nad nimi, která bude zahrnovat i další operace, ve kterých se tyto rodiny liší (například to ověření jména uživatele).

[Michal Kubeček]

Pak spousta socket options nastavovanych pres setsockopt(), s pouzivanych treba TCP_CORK, IP_TOS, IP_TTL.

Ještě jsem nepotřeboval nastavovat volby jindy než během inicializace.

Zrovna TCP_CORK je option, kterou dost dobře nelze nastavit jen při inicializaci. U IP_TOS nebo TCP_NODELAY jsou také situace, kdy by mělo smysl měnit hodnoty podle toho, jak se mění charakter komunikace (třeba u SMTP).

Na druhou stranu, pokud aplikace počítá s tím, že může používat jak PF_INET/PF_INET6 sockety, tak PF_UNIX, může samozřejmě nastavovat jen ty socket options, které mají pro daný typ socketu smysl.

[pavlix]

Predstava takove abstrakce me prijde dost absurdni.

Přitom už to někde viděl. Aplikace si prostě „localhost“ překládala jako AF_UNIX a odpovídající cestu.

nebo by to proste emulovalo TCP pomoci UNIX socketu

Něco podobného dělá patch, který tuto debatu rozvířil.

[Ondrej 'SanTiago' Zajicek]

Aplikace si prostě „localhost“ překládala jako AF_UNIX a odpovídající cestu.

Kde se neco takoveho realne dela?

Něco podobného dělá patch, který tuto debatu rozvířil

Ale zpusobem, ktere je pro programy daleko transparentnejsi.

[xkucf03]

Kde se neco takoveho realne dela?

Tohle dělá/dělal nějaký klient k MySQL, ale asi by se našlo víc příkladů. Pomohlo napsat 127.0.0.1 místo localhost.

[pavlix]

Ale zpusobem, ktere je pro programy daleko transparentnejsi.

To jistě.

[trekker.dk]

Kde se neco takoveho realne dela?

MySQL knihovna k PHP

[xkucf03]

Aplikace si prostě „localhost“ překládala jako AF_UNIX a odpovídající cestu.

Což není abstrakce, ale spíš šamanismus – takové aplikace mám opravdu rád. Např. když si člověk pracně protuneluje nějaký vzdálený port na localhost, chce se připojit, nejde to… a po chvíli zjistí, že aplikace si chytře vyložila localhost tak, že se má připojit na UNIXový soket na nějakém obvyklém místě v adresářové struktuře.

nebo by to proste emulovalo TCP pomoci UNIX socketu

Něco podobného dělá patch, který tuto debatu rozvířil.

Dělá a z principu je to úplně zcestné. Buď potřebuji jen vstupní a výstupní proud a pak mi dostatečnou abstrakci poskytuje stávající API* nebo potřebuji specifické** vlastnosti dané technologie a pak použiji ji – nemá cenu maskovat jednu technologii za jinou a klamat uživatele.

Optimalizace ano, ale nesmí nic rozbít ani se chovat podivně a nečekaně.

*) samozřejmě, že spojení se bude vytvářet vždycky trošku jinak – i když i tohle jde zobecnit, schovat za nějakou obalovou vrstvu, které předám URL a dostanu I/O proudy, takže se budou spojení dokonce i vytvářet stejným způsobem.

**) např. vědět, který uživatel se připojuje k unixovému soketu a mít možnost řídit práva stejně jako u souborů, nebo mít třeba síťovou transparentnost a možnost používání iptables pravidel.

[pavlix]

Což není abstrakce, ale spíš šamanismus – takové aplikace mám opravdu rád.

Je fakt, že mělo být použito něco neobsazeného, třeba NULL nebo prázdný řetězec. Taky o tom vím jen díky tomu, že mi to za nějakých okolností nefungovalo, stejně jako ty.

Dělá a z principu je to úplně zcestné. Buď potřebuji jen vstupní a výstupní proud a pak mi dostatečnou abstrakci poskytuje stávající API* nebo potřebuji specifické** vlastnosti dané technologie a pak použiji ji – nemá cenu maskovat jednu technologii za jinou a klamat uživatele.

Taky mám dojem, že TCP bypass je spíše kontraproduktivní technika, která ve skutečnosti neřeší chybějící funcionalitu kernelu, ale neschopnost nějaké googlí bezpečnostní služby, která je schopná pracovat pouze s AF_INET* a ne AF_LOCAL. Ale to je jen můj odhad, nic o tom nevím.

[Heron]

+1

[Michal Kubeček]

A co iptables pravidla, která by se měla aplikovat?

Pravidla netfilteru, queueing disciplines nebo síťové statistiky to obejde. Proto bych asi byl raději, kdyby to defaultně bylo vypnuté a zapnul si to jen ten, kdo bude chtít vyšší výkon lokálních TCP spojení za cenu toho, že některé funkce (které ale v takové situaci stejně nejspíš nebude využívat) nebudou správně fungovat. V upstreamu to zatím vypadá spíš na defaultně zapnuté (ten patch není ještě ani v net-next a poslední submitnutá verze byla s aktuálním jádrem dost rozbitá a všechny benchmarky a testy byly dělané na starších), uvidíme, co na to distribuce.

než že by OS měl dělat takovéhle hacky, podstrkávat nějaké přímé spojení a tvářit se, že je to TCP

"Takových hacků" jsou už teď spousty, např. veškeré *-offloading funkce nebo to, že se na lokální smyčce nepočítají checksumy v IP hlavičce (možná i TCP, to si z hlavy nepamatuji).

[xkucf03]

Proto bych asi byl raději, kdyby to defaultně bylo vypnuté a zapnul si to jen ten, kdo bude chtít vyšší výkon lokálních TCP spojení za cenu toho, že některé funkce (které ale v takové situaci stejně nejspíš nebude využívat) nebudou správně fungovat.

+1

[j]

Pokud by to bylo default, tak to beru jako kritickou bezpecnostni chybu a takovej kernel na zadnej muj stroj nesmi.

Mam na nich totiz par aplikaci, ktere zcele umyslne jedou pres tcp, ac umi i sockety.

[David Watzke]

Nic me na tom patchi nezhnusilo To je typek...