1 2 next »

1. Network drivers and infrastructure
2. In brief and Minor gems

Kernel Log: Coming in 2.6.38 (Part 3) – Network drivers and infrastructure

by Thorsten Leemhuis

Kernel version 38 will offer a new meshing implementation, loads of new and improved LAN and Wi-Fi drivers, plus various minor changes that promise to improve the network subsystem's performance.

All the parts in this Kernel Log mini-series can be found by reference to the 2.6.38 tracking page.

Early on the morning of 22 February, Linus Torvalds issued the sixth release candidate of Linux 2.6.38. In his release email, Torvalds mentioned a fix for a memory corruption problem – but he said that it is rare and only two people ever saw it. There was no indication of a final release date for 2.6.38. Usually released on a weekly basis, the "regression reports" have recently listed 17 unsolved problems which don't exist in 2.6.37; a further 26 flaws introduced between 2.6.36 and 2.6.37 also remain unsolved.

The Kernel Log takes the release of RC6 as an opportunity to continue its "Coming in 2.6.38" mini series and describe the advancements in terms of network hardware drivers and infrastructure. The first part of our mini series described the changes in the graphics hardware area, while the second part covered file systems. Over the coming weeks, further articles will discuss the kernel's storage, architecture and infrastructure code as well as its audio, USB, and video hardware drivers.

LAN

The XPS commit comment includes the results of various performance tests. After introducing Receive Flow Steering (RFS) and Receive Packet Steering (RPS) in 2.6.35, Google developer Tom Herbert has now submitted Transmit Packet Steering (XPS)  (1, 2, 3). With multi-queue network cards, these software components allow network queues to be associated with processor cores. In certain situations this improves processor cache efficiency and, consequently, increases the data throughput of fast network cards. The underlying idea is the same as that of RPS, with the exception that XPS relates to the sending, rather than the receiving, of network packets. As Herbert explains in the commit comment, on a test system with 16 processor cores and a network card with as many queues, XPS improved transmission performance by 20 per cent – although the chosen measuring technique did highlight the technology's advantages.

As in 2.6.37, Eric Dumazet has introduced numerous low-level network code optimisations (1, 2, 3, 4, 5). However, Dumazet isn't the only very active developer in this area at the moment – further similar improvements are accessible via the links in the "Minor gems" section at the end of this article. In various tests with different operating systems, Google found that some of the TCP stack's default settings aren't exactly ideal for modern internet communication.

A Google developer subsequently submitted a modification that enlarges the initial receive window. In 2.6.39, the developers plan to add another patch that enlarges the initial congestion window and is designed to reduce network communication latencies by 10 per cent; related background details can be found in the links to the patches and in the article "Increasing the TCP initial congestion window" on LWN.net.

Numerous minor improvements have been made in the LAN driver area. For example, the cnic driver now supports FCoE (Fibre Channel over Ethernet) with Broadcom's 57712 chip, the Vmxnet3 VMware driver offers multi-queue support, and ixgbe can address x540 chips.

Wi-Fi

Developed at open-mesh.org and previously located in the staging area, the batman-adv (Better Approach To Mobile Ad-Hoc Networking Advanced) meshing implementation has been enhanced to a degree that has allowed it to drop its "immature" status and move from the staging area to the network subsystem in 2.6.38 (1, 2). Background information on batman and batman-adv can be found in the article "Mesh networking with batman-adv" on LWN.net.

New additions to the Wi-Fi subsystem include the experimental rtl8192ce driver for Realtek's RTL8188CE and RTL8192CE 802.11n PCIe chips. Based on the Linux kernel's Wi-Fi stack, this driver was originally developed by Realtek. Long-time Linux Wi-Fi developer Larry Finger helped with integrating the driver into the Linux kernel and further Realtek drivers that are based on the Linux Wi-Fi stack are in preparation. These are signs that the long-term situation for Wi-Fi drivers for Realtek chips is improving. These chips have previously often been covered via drivers from the staging area for immature code – and staging drivers don't work seamlessly with such programs as the Network Manager and are, therefore, omitted altogether from some of the distributions.

Some of the Wi-Fi drivers have been extended to support new hardware – for example, the Atheros ath9k Wi-Fi driver now supports the AR9485 chip (1, 2, 3), and iwlwifi supports various new Intel Wi-Fi chips, such as the second-generation series 6000 chips that are mentioned in the updated Kconfig file. The driver now also offers Advanced Power Management, which is said to reduce power consumption with Intel's 6000g2b and its successors.

In the b43 driver, the developers have further modified the code to support various Broadcom 802.11n Wi-Fi chips; this code had already been extended, but not completed, in 2.6.37. The support is now said to be functional (for instance 1, 2, 3, 4). At the same time, the b43-specific configuration option for 802.11n support has been renamed and is no longer marked as "broken". Things are similar with the Rt2x00 drivers for Ralink's series RT30xx chips: initially rudimentary and available as an added option, the support for model RT3090, RT3091 and RT3092 PCI / PCIe chips and for model RT3070, RT3071 and RT3072 USB chips has now become a regular component of the rt2800pci and rt2800usb drivers.

On the other hand, the still rudimentary code to support Ralink RT3370 (USB) and RT3390 (PCI/PCIe) chips was given a dedicated option, as it can't quite start up these chips yet and is, therefore, currently mainly intended for testers and developers.

Next: In brief

1 2 next »