Seite 4: Netzwerkverbesserungen: Overhead-Vermeidung und Live Migration

Inhaltsverzeichnis

Laufende VMs trotz Host-Hardware-Assoziation umziehen

Der neue Treiber Net-Failover ermöglicht eine von Hypervisor kontrollierte Live-Migration von Virtual Machines (VMs), die Teilfunktionen des im Wirt steckenden Netzwerkchips verwenden (u. a. 1, 2, 3). Die Nutzung einer via SR-IOV bereitgestellten Virtual Function (VF) der NIC im Host bietet Performance-Vorteile – die Assoziation mit echter Hardware blockiert aber den Umzug einer VM zur Laufzeit, sofern der Admin nicht mit einem weiteren Netzwerkinterface sowie Bonding oder Teaming im Gast trickst.

Der neue Treiber ermöglicht die Live-Migration, indem er das VF-Gerät mit einer paravirtualisierten Virtio-Netzwerkschnittstelle des Hypervisors koppelt. Beide verwenden dieselbe MAC-Adresse, aber nur ein Interface wird aktiv genutzt. Beim Umzug wird die VF von der VM getrennt, woraufhin der Treiber automatisch zum Virtio-Interface wechselt. Die Netzwerkkonfiguration im Gast muss dabei nicht angepasst werden; auch Anwendungen sollen davon nichts mitbekommen, wenn man von Aspekten wie einer schlechteren Performance absieht. Dafür kann die VM anschließend auf einen anderen Host umziehen, wo wieder ein VF zugewiesen werden kann.

Mehr Performance mit mehr Programmieraufwand: TCP-Zerocopy

Das neue "TCP_ZEROCOPY_RECEIVE" ermöglicht Anwendungen, direkt auf empfangene TCP-Datenpakete zuzugreifen. Das erfordert zwar einen eigenen Codepfad in der Anwendung, kann beim Paket-Handling aber einen Kopiervorgang zwischen dem Speicherbereich des Kernels und dem der Anwendung vermeiden. Das erspart Prozessor und Arbeitsspeicher etwas Arbeit, was die Performance verbessert und Ressourcen für andere Aufgaben frei schaufelt. Empfangene Daten per Zerocopy zu erhalten klappt aber nur unter ganz bestimmten Bedingungen (u. a. einer MTU von 4K), die zwei Commit-Kommentare (1, 2) und zwei LWN.net-Artikel näher erläutern (1, 2) – das Ganze ist also etwas für Situationen, in denen Admins und Entwickler einiges an Arbeit zu investieren bereit sind, um die Performance zu steigern. Google macht das und verspricht sich viel davon, wie Notizen und eine Präsentation einer jüngst abgehaltenen Konferenz zeigen; bei seinen Bestrebungen nutzt das Unternehmen eine Library, um Anpassungen in Anwendungen zu vermeiden.

Mehr Performance mit mehr Programmieraufwand: AF_XDP

Viel Know-how und Programmierarbeit erfordert auch das neue "AF_XDP". Über dieses Feature können Anwendungen bei der Netzwerk-Schnellstraße XDP (Express Data Path) andocken, die bei Linux 4.8 eingeführt wurde. Sie ist dem normalen Netzwerkstack vorgeschaltet und erledigt einige Dinge (etwa Drop, Forward und Rewrite) direkt selbst. Für komplexere Aufgaben können Programme sich nun über AF_XDP beim XDP einklinken, wie es ähnlich über die Programmierschnittstelle AF_PACKET beim normalen Netzwerkstack funktioniert.

Letztlich soll AF_XDP eine schnellstmögliche Verarbeitung von Netzwerkpaketen ermöglichen, die unter dem Oberbegriff "High Performance Packet Processing" läuft und beispielsweise für flexibel programmierbare Netzwerk-Infrastruktur wichtig ist (Software Defined Networking/SDN). Bislang wird sowas häufiger mit Lösungen wie dem Data Plane Development Kit (DPDK) realisiert, die im Userspace arbeiten und den Kernel komplett ausbooten. Bei AF_XDP hingegen bleibt der Kernel involviert und behält die Oberhand.

Letztlich soll DPDK dadurch auch auf AF_XDP aufbauen können. Das erreicht wohl nicht ganz die bislang mit DPDK mögliche Performance, aber eine ähnliche, die für viele Einsatzzwecke ausreicht. Dafür können DPDK-spezifische Netzwerktreiber im Userspace entfallen; außerdem müssen sich Entwickler nicht mehr selbst um Sicherheitsbelange kümmern, die normalerweise der Kernel für sie erledigt.

AF_XDP bietet bei 4.18 alle wesentlichen Grundfunktionen, allerdings stehen Änderungen zur noch effizienteren Verarbeitung schon zur Aufnahme bereit; darunter Zerocopy-Support für AF_XDP, der schon so gut wie fertig ist. Weitere Details zu AF_XDP erläutern ein Commit mit Dokumentation und Programmierbeispiel, die Kommentare einiger Commits (u. a. 1, 2) und ein Artikel bei LWN.net.

Verbesserungen am BPF

Der Kernel bietet jetzt Eingriffspunkte bei Sockets, um von der BPF Virtual Machine ausgeführte Programme auszuführen, wenn eine Anwendung den Syscall sendmsg() verwendet. Das lässt sich etwa nutzen, um IP-Adressen ausgehender Pakete umzuschreiben.

Programmierer können das neue BPF Type Format (BTF) zum Speichern von Metadaten nutzen, die beschreiben, was die von Programmen angelegte Variablen oder Maps speichern. Dieser Weg lässt sich bei 4.18 nutzen, um in Maps gespeicherte Inhalte in Textform auszugeben (u. a. 1, 2). In Zukunft soll auch das Untersuchungswerkzeug bpftool das vom CTF (Compact C-Type format) abgeleitete Format nutzen können, um Daten übersichtlicher auszugeben; angedacht ist auch, Dwarf-Informationen in BTF zu überführen.

Auch auf 32-Bit-x86-Systemen kann der Kernel jetzt BPF-Code über einen Compiler mit JIT (Just in Time) übersetzen, um BPF-Code nicht indirekt über den BPF-Interpreter, sondern mit nativen Maschinenbefehlen auszuführen.

Feintuning für WLAN & TLS-Support

Bessere WLAN-Performance und weniger Staus in Netzwerken verspricht die neue Selective Acknowledgment (SACK) Compression im TCP-Stack. Durch sie verzögert der Kernel das Senden von SACK-Paketen, um diese dann komprimiert zu verschicken, falls sie denn überhaupt noch nötig sind. SACK-Pakete müssen verschickt werden, wenn ein TCP-Packet außer der Reihe eingeht. Das kann passieren, wenn es sich im Netzwerk gerade staut – gerade dann würden SACK-Pakete aber "Öl ins Feuer gießen", wie der Entwickler im Commit-Kommentar erläutert. Insbesondere bei WLANs, aber keineswegs nur dort soll das ein größeres Problem sein, das die Änderung mildert.

Der Kernel-Code kann die Datenverschlüsselung mit TLS (Transport Layer Security) jetzt an Netzwerkchips delegieren, die diese Aufgabe beherrschen. Das gelingt durch eine Erweiterung der Kernel-eigenen TLS-Unterstützung (Kernel TLS/KTLS), die bei Linux 4.13 eingeführt und jüngst bei 4.17 erweitert wurde. Damit das Auslagern funktioniert, muss auch der Netzwerktreiber das Ganze unterstützen; bei 4.18 beherrscht das nur der Treiber mlx5e (1, 2).

Darüber hinaus gab es noch allerlei andere Änderungen am Netzwerkcode, die ein Kommentar zum wichtigsten Merge Commit dieses Subsystems anreißt. Darunter sind unter anderem Support für Shifted Portmap Ranges bei NAT oder Unterstützung für Connlimit (Connection Limit) und Extended ACK Reporting in Nftables.