Kernel-Log – Was 2.6.35 bringt (3): Netzwerkunterstützung

Inhaltsverzeichnis

Seit der Freigabe der fünften Vorabversion von Linux 2.6.35 Anfang vergangener Woche gab es im Hauptentwicklungszweig nur einige kleinere Korrekturen und Verbesserungen. In Kürze dürfte vermutlich die sechste Vorabversion folgen und die Entwicklung von Linux 2.6.35 damit in die Endphase gehen.

Das Kernel-Log will daher die Mini-Serie "Was 2.6.35 bringt" mit der Beschreibung der Neuerungen rund um Netzwerk-Infrastruktur und -Treiber fortzusetzen. Der erste Teil der Mini-Serie hatte sich mit den Änderungen rund um Grafik-Hardware beschäftigt, der zweite mit Storage-Aspekten und Dateisystemen; folgen werden in den kommenden Tagen noch Artikel zu Treibern für USB, FireWire, V4L/DVB und Co. sowie Architektur-Code und Infrastruktur.

Mehr Durchsatz und kürzere Latenzen

Google-Entwickler Tom Herbert steuerte gleich zwei größere Verbesserungen am Netzwerk-Subsystem von Linux 2.6.35 bei: Receive Packet Steering (RPS) und Receive Flow Steering (RFS). Die erstgenannte Technik verteilt die Schritte zur Verarbeitung von empfangenen Netzwerkpaketen auf die verfügbaren Prozessorkerne, sodass diese die Verarbeitungsschritte ab der Protokollebene parallel erledigen; welche Kerne Arbeit zugewiesen bekommen lässt sich über eine via Sysfs setzbare Bitmaske festlegen. Zusammen mit anderen Funktionen emuliere RFS so letztendlich die Funktion von Multi-Queue-Netzwerkkarten in Software. Der Ansatz ist jedoch nicht ohne Nachteile, wie Herbert im Commit-Kommentar erwähnt – beste Performance sei erst nach System-spezifischem Tuning erreichbar und die Paketverarbeitung sei aufwendiger, daher könnte RPS auf einem nur teilweise ausgelasteten System die Performance negativ beeinflussen. Im Commit-Kommentar finden sich auch Ratschläge für den praktischen Einsatz sowie Testergebnisse, die der Technik eine teilweise erhebliche Steigerung des Netzwerkdurchsatzes bescheinigen.

Die zweite Technik baut auf der ersten auf und versucht die Abarbeitung der Layer 3 und 4 des Netzwerkprotokolls gleich auf den Prozessorkern zu lenken, auf der die Userspace-Applikation läuft, welche die Netzwerkdaten später annimmt und weiterverarbeitet. Wie das funktioniert, umreißt der Kernel-Hacker grob in Kommentar zum Commit im Quellcodeverwaltungssystem. Auch dieser enthält einige Messergebnisse, laut denen der Durchsatz im Vergleich zu RFS noch ein wenig weiter steigt; die Benchmark-Werte weisen zudem deutlich kürzere Latenzzeiten aus. Weitere Details zu den Techniken liefern auch Artikel zu RPS und RFS bei LWN.net.

Treiber

Einige weitere Neuerungen im Netzwerk-Stack sowie bei den Treibern für LAN- und WLAN-Hardware:

LAN:

• Der Kernel lädt nun automatisch als Modul kompilierte Treiber für Chips, die sich um das Physical Layer kümmern ("Ethernet PHYs"), wenn der Netzwerk-Treiber sie benötigt – man muss also nicht mehr manuell darauf achten, das Modul für den PHY vor dem Modul für den MAC zu laden.
• Der Treiber be2net unterstützt nun die für Virtualisierung interessante Single Root I/O Virtualization (SR-IOV) – kann also virtuelle Netzwerkkarten bereitstellen, die Gastsysteme direkt nutzen, was den Host entlastet und den Netzwerkdurchsatz teilweise deutlich steigert.
• Der für neuere Gigabit-Netzwerkchips von Intel geeignete Treiber e1000e sowie der für Realtek-Gigabit-Chips zuständige Treiber r8169 bieten nun Basisfunktionen zur Unterstützung der mit 2.6.34 eingeführten Techniken zur Nutzung der zur Laufzeit verwendbaren Stromsparmechanismen von I/O-Geräten. Wie in den Commit-Kommentaren erläutert müssen die Stromsparfunktion aber über Sysfs aktiviert werden, damit die Chips etwa schlafen gehen, wenn kein Netzwerkkabel angeschlossen ist.
• Die Treiber bnx, bnx2x und forcedeth unterstützen nun die bei 2.6.29 eingeführte Generic Receive Offload (GRO) Infrastructure.

WLAN:

• Neu zum Kernel stieß der WLAN-Treiber ath9k_htc für WLAN-Hardware mit den Atheros-Chipsätzen AR7010 oder AR9271.
  
• Für die ältlichen, einen USB-Chip einsetzenden Agere-WLAN-Karten der Orinoco-Serie bringt der Kernel nun den Treiber orinoco_usb mit.
• Durch eine Implementation von Adaptive Noise Immunity (ANI) soll der für ältere Atheros-WLAN-Chips geeignete Treiber ath5k nun höhere Übertragungsraten in Umgebungen erreichen, wo es viele Signalstörungen gibt; bei Tests in einer solchen habe der Patch die Übertragungsrate nahezu verdoppelt.
• Die Unterstützung der für USB oder PCI ausgelegten Ralink-Chipsätze der Rt30xx-Serie im Treiber rt2x00 wird nun standardmäßig aktiviert, da diese nun ähnlich weit gereift sei wie der Support für die Rt28xx-Chips.
• Intel hat die Betreuung der ipw2x00-Treiber aufgegeben, die die 802.11b-WLAN-Module ansprechen, die vornehmlich in Centrino-Notebooks der ersten und zweiten Generation verbaut wurden. Die Intel-Entwickler mussten sich für diesen Schritt aber Kritik von Netzwerk-Subsystem-Maintainer David Miller anhören, da Intel keine Dokumentation zu den von den Treibern unterstützten WLAN-Chips veröffentlicht habe, was die weitere Treiber-Pflege erheblich erschwert.

David Miller hebt in der Zusammenfassung der wichtigsten Änderungen seines Haupt-Git-Pull-Request noch einige weitere Neuerungen hervor – darunter die Multiple Multicast Routing Tables (1, 2, 3, 4), IPV6 Bridge Multicast Snooping und Port-Reservierung. Neu ist auch die Unterstützung für das von ST-Ericsson entwickelte und für Modems eingesetzte Protokoll CAIF (u. a. 1, 2, 3, Dokumentation). Außerdem beherrscht der Kernel nun die Version 3 des Layer 2 Tunneling Protocol (L2TP) (u. a. 1, 2, 3, Dokumentation). Sysfs bietet nun Tagged Directories, was die auch an deren Stellen des Kernels ausgebaute Unterstützung für eine Netzwerk-Namespace-spezifische Einbindung der virtuellen Dateisystemen Procfs und Sysfs verbessert.