Názory k článku Aplikační WireGuard-Go je teď dvakrát rychlejší než jaderná implementace

Díky za parádní článek

Tohle je moc pěkné. Určitě by se to hodilo i pro OpenVPN.

nereformovatelné OpenVPN je už naštěstí mimo hru. V minulosti to zatěžovalo všechny stroje, žralo baterii mobilům a způsobovalo leaky. Čest jeho památce.

Zajímavé je, že podle white paperu Wireguarda se podobný trik se segmentací uvnitř wireguardu v jaderné implementaci už používá:

The WireGuard device driver has flags indicating to the kernel that it supports generic segmentation offload (GSO), scatter gather I/O, and hardware checksum offloading, which in sum means that the kernel will hand “super packets” to WireGuard, packets that are well over the MTU size, having been priorly queued up by the upper layers, such as TCP or the TCP and UDP corking systems. This allows WireGuard to operate on batch groups of outgoing packets. After splitting packets into ≤MTU-sized chunks, WireGuard attempts to encrypt, encapsulate, and send over UDP all of these at once, caching routing information, so that it only has to be computed once per cluster of packets.

Ono je to vůbec celé dost podezřelé. U implementace v jádře totiž GSO/GRO až tak zásadní efekt mít nebude, protože na rozdíl od userspace implentace sedící na tun rozhraní se absence nebude projevovat počtem syscallů (a hlavně context switchů). Takže mám silné podezření, že důvod, proč jim implementace v jádře vychází tak špatně, bude ve skutečnosti v něčem jiném. Koneckonců, bez šifrování zvládnu nasytit 10Gb/s ethernet jedním TCP spojením i s vypnutým GSO/GRO, a to i na ne úplně aktuálním CPU.

Moderní syscalls už nejsou tak drahé jako za časů, kdy se volaly přes interrupt, takže rozdíl může mezi userspace a system může být poměrně zanedbatelný.

Ale dole budou všelijaké zámky a reference counts, u kterých záleží, jestli se provedou jednou pro více bufferů nebo pro každý buffer.

U normální aplikace je to jedno, ale u tohoto, kde jde čistě o IO throughput, to může udělat velký rozdíl.

> Moderní syscalls už nejsou tak drahé jako za časů, kdy se volaly přes interrupt, takže rozdíl může mezi userspace a system může být poměrně zanedbatelný.

Ale zase máme Meltdown a s tím související flushe různých TLB a cache, ne?

To je pravda, pokud tím procesor trpí. Asi bude záležet, kolik si WireGuard vezme paměti a jak se mazání cache projeví v benchmark. Obojí (cache i frekvence syscalls) může být ale dost odlišné od reálného provozu, takže benchmark na maximální výkon může být dost zavádějící...

V každém případě by bylo zajímavé měření na procesoru s ochranou proti side channel attacks a bez ní.

Režie syscallu je především v tom, že je potřeba provést context switch mezi userspace a jádrem, a jeho režie se v poslední době spíš zhoršila (page table isolation).

Co se týká efektivity, tak GSO/GRO je pro vysoké rychlosti nutnost, ale mám opakovaně vyzkoušené, že 10 Gb/s není velký problém dosáhnout is s vypnutým GSO/GRO, takže proto tvrdím, že problém bude spíš v něčem jiném. Je docela škoda, že se nikdo pořádně nepodíval na perf profil toho testu s implementací v jádře, protože ten závěr "bude to asi stejný problém" je zcela nepodložený.

V článku se píše:
Obě strany si při seznámení sdělí svůj požadavek na limit MSS, přičemž nižší hodnota vyhrává. Obě strany se pak tímto omezením řídí a neposílají si větší segmenty.

Měl jsem za to, že MSS každá strana jen oznámí té druhé a ta se tím pak řídí. Tj. MSS může být pro každý směr jiné.

https://www.ibm.com/support/pages/what-mss-maximum-segment-size-and-how-it-calculated

Měl jsem za to, že MSS každá strana jen oznámí té druhé a ta se tím pak řídí. Tj. MSS může být pro každý směr jiné.

Ano, je to tak.

Opravdu povedeny clanek.
Az na ten nadpis (jestli mi tedy neco neunika?).
Mel jsem za to, ze vtip wireguardu je mimo jine v tom, ze jde po udp a prezije zmenu ip adresy/portu koncoveho bodu. Takze optimalizace tcp spojeni uvnitr vpn podle vlastnosti linky je naprosto okrajova technika, ktera vubec nevypovida o rychlostech v beznem nasazeni.

Marek

Asi bych řekl, že spíš uniká. Proč by měla být optimalizace přenosu TCP segmentů naprosto okrajovou technikou? Drtivá většina internetových protokolů používá TCP, mimo jiné prakticky všechny protokoly pro přenos velkých objemů dat.

Naopak je s ohledem na rychlost zcela irelevantní jestli wireguard dokáže nebo nedokáže přežít změnu IP adresy/portu koncového bodu.

Naprosto drtiva vetsina prenosu velkych dat pomoci TCP zapouzdreneho ve VPN NEPROBIHA v ramci 1 datoveho centra po zname infrastrukture s jumboframes.
Ja osobne nevim o nikom, kdo by takto (misto vlan, vxlan, ...) jakoukoli vpn pouzival.
Budto to pouzivaji jako nahradu pronajateho vlakna, nebo na pripojovani do firmy z nejasne konektivity. Vetsinou nemaji presne garantovano, ze se nebudou po ceste vlastnosi linky v case menit, ze se nezmeni poradi packetu, ze se nebudou ztracet....
Ja kdyz si prectu nadpis: "Aplikační WireGuard-Go je teď dvakrát rychlejší než jaderná implementace"
Tak mam proste pocit, ze by to melo mit vetsinou vyssi propustnost a nizsi latenci.
To mi potom z clanku ani nahodou nevyplyva.

Marek