Kernel-Log – Was 2.6.38 bringt (3): Netzwerk
Der 38er-Kernel bringt eine neue Mesh-Implementierung, haufenweise neue und ĂĽberarbeite LAN- und WLAN-Treiber und einige kleine Verbesserungen, die die Performance des Netzwerk-Subsystems steigern sollen.
- Thorsten Leemhuis
In der Nacht von Montag auf Dienstag hat Linus Torvalds die sechste Vorabversion von Linux 2.6.38 freigegeben. Er erwähnt dabei eine Korrektur für einen Fehler, der den Arbeitsspeicher durcheinander gebracht hat – vermutlich habe das Problem aber nur zwei Leute betroffen. Hinweise zum Veröffentlichungszeitpunkt von 2.6.38 gab er keine. Die zumeist wöchentlich veröffentlichte "Regression Reports" listen kürzlich 17 ungelöste Probleme, die 2.6.37 nicht zeigt; zudem waren noch 26 Fehler offen, die sich zwischen 2.6.36 und 2.6.37 eingeschlichen haben.
Das Kernel-Log nimmt die fortschreitende Entwicklung des 38er-Kernels zum Anlass, die Mini-Serie "Was 2.6.38 bringt" mit der Beschreibung der Neuerungen rund um Treiber und Infrastruktur für Netzwerk-Hardware fortzusetzen. Der erste Teil der Serie hatte sich mit den Änderungen rund um Grafik-Hardware beschäftigt, der zweite mit Dateisystemen; folgen werden in den kommenden Wochen noch Artikel zu Storage, Architektur- und Infrastruktur-Code sowie Treibern für Audio-, USB- und Video-Hardware.
LAN
Nach den bei 2.6.35 integrierten Techniken Receive Flow Steering (RFS) und Receive Packet Steering (RPS) hat Google-Entwickler Tom Herbert nun das Transmit Packet Steering (XPS) eingebracht (1, 2, 3). Darüber lässt sich bei Multiqueue-Netzwerkkarten eine Zuordnung zwischen Netzwerk-Queue und Prozessorkern festlegen, was die Effizienz der Prozessor-Caches in bestimmten Situationen verbessert und so den Datendurchsatz bei schnellen Netzwerkkarten steigert – die Idee dahinter ist somit die selbe wie bei RPS, nur das es nicht um das Empfangen, sondern das Senden von Netzwerkpaketen geht. Auf einem Testsystem mit 16 Prozessorkernen und einer Netzwerkkarte mit ebenso vielen Queues stieg die Sendeleistung durch XPS um 20 Prozent, wie Herbert im Commit-Kommentar erläutert – das Messverfahren war allerdings auch darauf ausgelegt, die Vorteile der Technik zu zeigen.
Wie schon bei 2.6.37 hat Eric Dumazet zahlreiche Low-Level-Optimierungen am Netzwerk-Code vorgenommen (u. a. 1, 2, 3, 4, 5). Er ist aber nicht der einzige Entwickler, der derzeit auf diesem Gebiet sehr aktiv ist – weitere Verbesserungen dieser Art finden sich über die Links im Abschnitt "Die kleinen Perlen" am Ende des Artikels. Google hat bei einigen Tests mit verschiedenen Betriebssystemen festgestellt, dass einige Standard-Vorgaben im TCP-Stack für moderne Internet-Kommunikation nicht unbedingt ideal sind. Eine daraufhin durch einen Google-Entwickler eingebrachte Änderung vergrößert das Initial Receive Window. Bei 2.6.39 soll ein darauf aufbauender Patch folgen, der auch das Initial Congestion Window vergrößert und dadurch Latenzen bei der Netzwerkkommunikation um 10 Prozent reduzieren soll; Hintergründe dazu finden sich in den Links zu den Patches sowie der LWN.net-Meldung "Increasing the TCP initial congestion window".
Bei den LAN-Treibern gab es zahlreiche kleinere Verbesserungen: cnic unterstĂĽtzt nun etwa FCoE (Fibre Channel over Ethernet) auch beim Broadcom-Chip 57712, der VMware-Treiber Vmxnet3 bietet Multiqueue Support und ixgbe spricht auch die x540-Chips an.
WLAN
Die im Rahmen von open-mesh.org entwickelte und bislang im Staging-Bereich angesiedelte Mesh-Implementierung batman-adv (Better Approach To Mobile Ad-Hoc Networking Advanced) wurde so weit verbessert, dass sie mit 2.6.38 das Siegel "unreif" ablegt und vom Staging-Bereich in das Netzwerk-Subsystem umzieht (1, 2); einige HintergrĂĽnde zu Batman und Batman-adv liefert LWN.net in dem Artikel "Mesh networking with batman-adv".
Zum WLAN-Subsystem stieß der als experimentell gekennzeichnete Treiber rtl8192ce für Realteks 802.11n-PCIe-Chips RTL8188CE und RTL8192CE. Realtek hat diesen auf dem WLAN-Stack des Linux-Kernels aufbauenden Treiber ursprünglich selbst entwickelt; bei der Integration in den Linux-Kernel hat der langjährige Linux-WLAN-Entwickler Larry Finger geholfen; weitere Realtek-Treiber auf Basis des Linux-WLAN-Stack sind in Vorbereitung. Damit zeichnet sich langfristig eine Besserung der Lage bei WLAN-Treiber für Realtek-Chips ab, denn für die waren bislang häufig Treiber aus dem für unreifen Code gedachten Staging-Bereich nötig. Die arbeiten mit Programmen wie dem NetworkManager nicht perfekt zusammen und bleiben bei manchen Distributionen daher sogar außen vor.
Auch einige der WLAN-Treiber wurden um Unterstützung für neue Hardware erweitert – der Atheros-WLAN-Treiber ath9k spricht jetzt etwa den Chip AR9485 an (1, 2, 3) und iwlwifi unterstützt einige neue, in der aktualisierten Kconfig-Datei erwähnte WLAN-Chips von Intel wie die zweite Generation der 6000er-Chips. Der Treiber bietet jetzt auch Advance Power Management, was die Leistungsaufnahme bei Intels 6000g2b und dessen Nachfolgern reduzieren soll.
Die schon bei 2.6.37 im Treiber b43 ausgebaute, aber zu der Zeit noch unvollständige Unterstützung für einige 802.11n-WLAN-Chips von Broadcom wurde weiter überarbeitet und soll jetzt funktionieren (u. a. 1, 2, 3, 4); in dem Zuge wurde die b43-spezifische Konfigurations-Option zur Unterstützung von 802.11n-Chips umbenannt und verliert die Auszeichnung "Broken". Ähnlich verhält es sich bei den Rt2x00-Treibern für Ralink-Chips der RT30xx-Serie: Die anfangs rudimentäre und über Option zuschaltbare Unterstützung für die PCI-/PCIe-Chips RT3090, RT3091 und RT3092 sowie die USB-Chips RT3070, RT3071 und RT3072 ist nun regulärer Bestandteil der Treiber rt2800pci und rt2800usb. Eigene Optionen erhielt hingegen der noch rudimentäre Code zur Unterstützung der Ralink-Chips RT3370 (USB) und RT3390 (PCI/PCIe), denn er kann diese Chips noch nicht recht in Betrieb nehmen und richtet sich daher fürs erste nur an Tester und Entwickler.
