Kernel-Log – Was 3.19 bringt (2): Netzwerk

Linux-Distributionen sollen mittelfristig ohne spezielle Anpassungen als Switch-Betriebssystem arbeiten können. Neu ist ein Treiber zum Vernetzen von Containern. Fehlgeschlagen ist hingegen der Versuch, die Wireless Extensions zu entfernen, denn Linus Torvalds ist Abwärtskompatibilität überaus wichtig.

In Pocket speichern vorlesen Druckansicht 30 Kommentare lesen
Lesezeit: 5 Min.
Von
  • Thorsten Leemhuis
Inhaltsverzeichnis

Das Netzwerk-Subsystem des Linux-Kernels enthält nun eine Infrastruktur, mit denen Treiber viele Switching- und Routing-Aufgaben an Hardware-Bausteine delegieren können, die für solche Aufgaben geschaffen wurden (u. a. 1, 2). Dadurch sollen sich universelle Linux-Distributionen mittelfristig als Betriebssysteme für Switches eignen, wie sie in Rechenzentren stehen. Diese "Linux-Switches" könnte man mit bekannten Linux-Programmen wie den Iproute2-Werkzeugen, Nftables oder Open vSwitch transparent verwalten; sie wären flexibler und leichter zu handhaben als aktuelle Modelle, die häufig proprietäre Software einsetzen.

Es sind aber noch passende Treiber nötig, bevor universelle Linux-Distributionen in den Markt für Switch-Betriebssysteme vordringen können. Der Kernel 3.19 bringt nämlich lediglich einen als Referenzimplementierung gedachten Treiber "rocker" mit, der die neue Infrastruktur nutzt; er unterstützt allerdings keinen echten Switching- und Routing-Chip, sondern einen von Qemu emulierten (1, 2).

Was Linux 3.19 bringt

Linux 3.19 erscheint vermutlich zu Beginn der zweiten Februar-Woche, wie Linus Torvalds bei der Freigabe der siebten Vorabversion andeutete. Größere Umbauarbeiten sind keine mehr zu erwarten, denn alle wesentlichen Neuerungen haben die Kernel-Hacker bereits im Dezember integriert. Das Kernel-Log konnte daher bereits vor der Fertigstellung einen Überblick über die wichtigsten Änderungen dieser Version liefern. Das erfolgt mit der vierteiligen Artikelserie "Was 3.19 bringt", die sich nach und nach den verschiedenen Bereichen des Kernels gewidmet hat:

Der Systemaufruf getsockopt() unterstützt nun die Option SO_INCOMING_CPU. Anwendungen können darüber Informationen zu dem Prozessorkern erhalten, der sich um die physischen Netzwerk-Übertragungen eines Sockets kümmert. Wenn dann auch die Datenverarbeitung auf diesem Kern läuft, vermeidet das ein Kopieren der Daten zwischen Prozessorkernen. Das kann den Netzwerkdurchsatz bei leistungsstarken Mehrprozessor-Systemen mit Multi-Queue-Netzwerk-Hardware deutlich steigern.

Dem Kernel liegt nun der Treiber Ipvlan bei, der zur Einrichtung von Netzwerkverbindungen zwischen Containern eines Systems entwickelt wurde. Er erledigt somit ähnliches wie der Treiber Macvlan, der virtuelle Maschinen eines Hosts effizient verbinden kann; Ipvlan greift bei den Routing-Entscheidungen aber auf Informationen aus einem höheren Layer des Netzwerkstacks zurück. Details zur Funktionsweise erläutert die Treiber-Dokumentation.

Auf Extended Berkeley Packet Filter (eBPF) aufsetzende Programme können nun an Netzwerk-Sockets andocken (u. a. 1, 2, 3). Bislang wird das nur zum Erfassen von statistischen Daten genutzt, aber durch diese und andere Änderungen sind weitere Einsatzmöglichkeiten denkbar, wie parallel zum Kernel hinzugefügte Beispiele zeigen (1, 2, 3, 4).

So lassen sich nun nicht mehr nur zustandlose (stateless) BPF-Filter programmieren, sondern auch zustandsbehaftete (stateful) – etwa um mit eBPF-Programmen Datenströme zu verfolgen oder die Zahl der pro IP-Adresse verarbeiteten Pakete zu erfassen; Datails erläutert ein LWN.net-Artikel. Der noch junge und derzeit mit jeder Kernel-Version verbesserte eBPF zeigt damit mehr und mehr sein Potential; mittelfristig soll er auch beim Tracing und in anderen Bereichen zum Einsatz kommen, um relevante Informationen effizient aus großen Datenmengen abzugreifen.

Ab Kernel 3.19 lässt sich die Verwendung von Explicit Congestion Notification (ECN) nicht mehr nur global, sondern auch pro Route festlegen. Die TCP-Erweiterung zur Vermeidung von Überlastung lässt sich so auch in Rechenzentren einsetzen, bei denen Router oder Firewall auf einzelnen Netzwerkpfaden nicht mit ECN harmonieren; das kann etwa bei Internetdienstleistern der Fall sein, die Video- oder Streaming-Dienste anbieten wollen.

Ein Google-Mitarbeiter hat Unterstützung für das von ihm entwickelte Remote Checksum Offload (RCO) eingebracht. RCO ist eine beim IETF derzeit als Internet-Draft gehandelte Technik, bei der die Netzwerk-Hardware auf Empfänger-Seite die Checksumme von Paketen setzt, die gekapselt in Paketen stecken, die per UDP oder GRE ausgetauscht werden. Das reduziert die Prozessorlast auf Sendeseite und schöpft die Fähigkeiten moderner Netzhardware besser aus.

Das für Network Virtualization verwendete Open vSwitch beherrscht nun Multiprotocol Label Switching (MPLS), das den Transportweg in großen Netzen optimieren kann.

Unter dem größten Schwung mit Änderungen am Netzwerksubsystem war zudem ein Patch, der die Konfigurations-Option unsichtbar gemacht hat, über die sich der Kompatibilitätscode für die Wireless Extensions (WEXT) aktivieren ließ – eine Technik, über die WLAN-Chips in der Anfangszeit der Technik konfiguriert wurden. Über WEXT sprechen auch Tools wie Iwconfig oder Iwlist mit dem Kernel, die das modernere und mächtige Iw seit Jahren zu ersetzen versucht. Diese und andere WEXT-Tools sind aber offenbar noch viel im Einsatz und funktionierten nach der Änderungen nicht mehr, daher wurde sie flugs zurückgenommen.

Torvalds betonte zum wiederholten Mal die Wichtigkeit von Abwärtskompatibilität.

(Bild: gmane.org)

Auch eine schon 2013 vorgenommene Änderung am Code für die ARM-Architektur wurde für 3.19 zurückgenommen, weil jemand meldete, dass ein Programm seitdem nicht mehr funktioniert. Vor der Rücknahme beider Änderungen gab es Diskussionen, in denen Torvalds erneut und mit deutlichen Worten die Wichtigkeit von Abwärtskompatibilität betonte; er will damit sicher stellen, dass Tester und Anwender keine Angst haben müssen, dass nach dem Wechsel auf eine neuere Kernel-Version irgendetwas nicht mehr funktioniert. Weitere Hintergründe zu den Rücknahmen und Diskussionen erläutert der englische LWN.net-Artikel "Haunted by ancient history".

Weitere Hintergründe und Informationen rund um Entwicklungen im Linux-Kernel und dessen Umfeld finden sich in den vorangegangenen Kernel-Logs auf heise open. Neue Ausgaben des Kernel-Logs werden über das Twitter-Konto "@kernellog" annonciert. (thl) (thl)