Kernel-Log – Was 3.3 bringt (1): Netzwerk

Kernel 3.3 bietet eine neue Möglichkeit zum Zusammenschalten von Netzwerk-Ports. Neu ist auch Unterstützung für den virtuellen Netzwerk-Switch "Open vSwitch", der speziell zur Virtualisierung entwickelt wurde. Byte Queue Limits sollen die Wartezeiten reduzieren, die zum viel diskutierten "Buffer Bloat" führen.

In Pocket speichern vorlesen Druckansicht
Lesezeit: 15 Min.
Von
  • Thorsten Leemhuis
Inhaltsverzeichnis

Mit der Freigabe von Linux 3.3-rc1 hat Linus Torvalds letzte Woche das Merge Window von Kernel 3.3 beendet. Bis zur Fertigstellung von Linux 3.3 wird er jetzt nur noch Fehlerkorrekturen und kleine Verbesserungen integrieren – die erste Vorabversion von Linux 3.3 enthält daher bereits die wichtigen Neuerungen der März erwarteten Kernel-Version. Es ist selten, dass die Kernel-Entwickler in der Stabilisierungsphase des Entwicklungszyklus noch größere Änderungen aufnehmen oder bereits aufgenommene Änderungen wieder rauswerfen oder deaktivieren.

Das Kernel-Log kann daher bereits jetzt einen umfassenden Überblick über die wichtigsten Neuerungen der Kernel-Version 3.3 geben.Wie gewohnt erfolgt die Übersicht in einer Artikelserie "Was 3.3 bringt", die sich nacheinander den unterschiedlichen Funktionsbereichen des Kernels annimmt. Den Anfang macht die Beschreibung der wichtigsten Änderungen am Netzwerk-Stack und an den Treibern für LAN- und WLAN-Hardware; in den kommenden Wochen folgen Artikel zu Storage, Dateisystemen, Architektur-Code, Infrastruktur sowie zu Treibern für sonstige Hardware.

Die Kernel-Entwickler haben einen Ethernet-Teaming-Treiber aufgenommen, der mehrere Netzwerk-Ports zu einem virtuellen verbindet (Link Aggregation/802.1AX). Dieses virtuelle Netzwerk-Device kann die Arbeit in einem Round-Robin-Verfahren über mehrere Ports verteilen; alternativ kann ein Port auch als "Active-backup" bereitstehen und einspringen, wenn es Probleme mit dem primär genutzten Netzwerk-Anschluss gibt. Die Entwickler empfehlen den Treiber als sehr schnelle, einfache und gut skalierende Alternative zum Bonding-Treiber, der ähnliches schon länger ermöglicht. Der Team-Treiber macht die Arbeit allerdings nicht komplett alleine, sondern arbeitet mit der Userspace-Bibliothek Libteam zusammen.

In Linux 3.3 sind die Kernel-Komponenten von Open vSwitch eingeflossen. Dieser Multilayer Virtual Switch kann auf den Layern 2, 3 oder 4 arbeiten und wurde speziell für den Einsatz im Virtualisierungsumfeld entwickelt; er kommt unter anderem beim XenServer 6.0 im Einsatz, um den Netzwerkverkehr zwischen Wirt, Gästen und Außenwelt zu steuern. Hintergründe zur Technik liefert die Open-vSwitch-Website, die dort angebotene Dokumentation, die Kernel-Dokumentation und ein als Video abrufbarer Vortrag, den Simon Horman Mitte Januar auf der Open-Source-Konferenz linux.conf.au 2012 gehalten hat:

Empfohlener redaktioneller Inhalt

Mit Ihrer Zustimmmung wird hier ein externes YouTube-Video (Google Ireland Limited) geladen.

Ich bin damit einverstanden, dass mir externe Inhalte angezeigt werden. Damit können personenbezogene Daten an Drittplattformen (Google Ireland Limited) übermittelt werden. Mehr dazu in unserer Datenschutzerklärung.

Über die Network Priority Cgroup Infrastructure können Administratoren bei Linux 3.3 dynamisch die Priorität festlegen, mit der Prozesse einer Control Group (Cgroup) die Netzwerk-Ressourcen nutzen können; Details erläutert die zugehörige Dokumentation. Durch den ebenfalls neuen "TCP buffer size controller" kann der Memory Controller die Menge des Arbeitsspeichers begrenzen, den die bei der TCP-Kommunikation verwendeten Puffer belegen dürfen (u. a. 1, 2, 3, 4, 5); diese Zwischenspeicher können recht groß werden und daher Systeme mit knapp bemessenen Arbeitsspeicher ins Straucheln bringen, wie ein LWN.net-Artikel zu einer früheren Variante der jetzt eingeflossenen Patches erläutert.

Über die von einem Google-Entwickler eingebrachten "Dynamic Queue Limits" und den darauf aufbauenden "Byte Queue Limits" kann der Kernel steuern, wie viele Daten sich in der Sende-Warteschlange ansammeln dürfen. Das soll die Netzwerk-Latenzen reduzieren helfen, die gelegentlich durch zu ausgiebige Nutzung der Zwischenspeicher in modernen Netzwerkchips entstehen, ohne den Durchsatz zu verringern und so das "Buffer Bloat"-Problem mindern, das durch zu exzessives Puffern von Daten in Netzwerk-Hardware entstehen. Die wichtigsten Netzwerk-Treiber – darunter bnx2, bnx2x, forcedeth, e1000e, igb, niu, tg3, sfc und sky2 -- erhielten Anpassungen, um Byte Queue Limits zu unterstützen. Einige Hintergründe zur Technik erläutert der LWN.net-Artikel "Network transmit queue limits".

Der von Broadcom selbst vorangetriebene WLAN-Treiber brcmsmac nutzt nun den schon länger im Kernel enthaltenen Treiber bcma, um die WLAN-Funktionseinheiten von Chips anzusprechen, die Broadcoms AMBA-Interconnect nutzen; zusammen mit einer anderen Änderung vermeidet das Situationen, wo zwei Treiber in Konflikte geraten, weil sie die selbe Hardware ansprechen.

In den Atheros-Treiber ath9k sind Änderungen zur Unterstützung von Dynamic Frequency Selection (DFS) eingezogen. Die Technik soll verhindern, dass WLANs bestimmte Frequenzbereiche im 5-GHz-Bereich verwenden, wenn sie dort Radar stören würden. Vollwertige Unterstützung für DFS im WLAN-Subsystem ist noch in Arbeit; Hintergründe zu DFS finden sich im Linux-Wireless-Wiki und bei LWN.net.

Der Netzwerktreiber hv_netvsc für Microsofts Virtualisierungsschnittstelle Hyper-V ist nach Jahren im Staging-Bereich nun so weit gereift, dass er in das Netzwerk-Subsystem umziehen durfte. Damit sollte er damnächst auch in Distributionen auftauchen, die keine oder nur einzelne Treiber aus dem Bereich für verbesserungsbedürftigen Code mitliefern.

Der Treiber tg3 unterstützt nun den Broadcom-Chip 57766; der Treiber ixgbe spricht zwei neue Ausführungen von Intels 82599 an (1, 2). Der Virtio-Net-Treiber, über den Wirt- und Gastsysteme Netzwerkdaten per Paravirtualisierung austauschen, unterstützt jetzt ACPI S4 (Ruhezustand/Hibernate).

Der Netzwerk-Code kann beim Active Queue Management (AQM) nun mit einem Adaptive RED (Random Early Detection) genannten Mechanismus arbeiten, der die Schwellwerte für Random-drop/Tail-drop dynamisch an den Datenverkehr anpasst. Durch diesen Ansatz soll die Technik, mit der sich Router selbst vor Überlastung schützen, robuster arbeiten, wie ein 2001 präsentiertes Paper zu Adaptive RED erläutert.

Netzwerk-Subsystem-Maintainer David Miller erläutert viele der hier erwähnten und einige weitere Änderungen in seinem Haupt-Git-Pull-Request für Linux 3.3. Dort hebt er beispielsweise die neue Unterstützung für Netlink Socket Dumping bei UDP- und AF_UNIX-Sockets hervor (u. a. 1, 2, 3, 4, 5).

Viele kleinere, aber keineswegs unbedeutende Neuerungen finden sich in der folgenden Liste mit den englischen Commit-Überschriften der jeweiligen Änderung. Die Einträge verlinken genau wie viele Verweise im vorangegangenen Text auf das Webfrontend des von Linus Torvalds gepflegten Git-Zweigs auf Kernel.org, der die Quellen des "offiziellen" Kernels enthält. Der Commit-Kommentar und der darunter ausgegebene Patch liefern zahlreiche weitere Informationen zur jeweiligen Änderung.

Vor jedem Link finden sich in eckigen Klammern einige Buchstaben und Zahlen. Ein "C" kennzeichnet Patches mit Änderungen an Kconfig-Dateien; diese enthalten die Konfigurationsoptionen samt der zugehörigen Hilfetexte, die bei der Kernel-Konfiguration über "make menuconfig" oder "make xconfig" angezeigt werden. Ein "D" steht bei Patches, die die Dokumentation verändern, die im Kernel-Zweig unterhalb von Documentation/ liegt. Ein "N" weist Änderungen aus, die eine neue Datei anlegen. Die Zahl vermittelt einen groben Eindruck zur Größe des Patches: eine "1" kennzeichnet Änderungen, die inklusive Kommentar zwischen 10 und 20 KByte groß sind, eine "2" für solche, die zwischen 20 und 30 KByte Umfang haben; Änderungen ohne Zahl sind kleiner als 10 KByte, Patches mit einer "9" hingegen 90 KByte oder größer.

LAN

WLAN

Various

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 auf den Identi.ca- und Twitter-Konten "@kernellog" erwähnt; die englischen, bei den Kollegen von "The H" erscheinenden Übersetzungen auf den Identi.ca- und Twitter-Konten "@kernellog2". Gelegentlich zwitschert der Autor des Kernel-Logs unabhängig davon über einige Kernel-Log-Themen bei Identi.ca und Twitter als "@kernellogauthor". (thl) (thl)