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

[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...