Vlákno názorů k článku Aplikační WireGuard-Go je teď dvakrát rychlejší než jaderná implementace od Ondřej Caletka - Zajímavé je, že podle white paperu Wireguarda se...

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