1 2 next »

Kernel Log: Coming in 2.6.35 (Part 3) - Network support

by Thorsten Leemhuis

Several patches submitted by a Google developer will enable the kernel to push considerably more data through network cables on multi-core systems. Some of the LAN and Wi-Fi drivers also promise greater throughput, or to use less power, due to various driver enhancements.

Since the fifth RC of Linux 2.6.35 early last week, the developers have only added minor corrections and improvements to the main development branch. It's likely that Torvalds will issue the sixth release candidate any day now, and the 2.6.35 kernel is likely to enter the final development stage.

This edition of the "Coming in 2.6.35" mini series describes the advancements in network infrastructure and drivers. Part one described the changes in the graphics hardware area and part two dealt with storage aspects and file systems. Future articles in this series will discuss the USB, FireWire and V4L / DVB etc drivers as well as the architecture code and infrastructure.

More throughput, less latency

Google developer Tom Herbert submitted two major improvements to the network subsystem of Linux 2.6.35: Receive Packet Steering (RPS) and Receive Flow Steering (RFS). RPS distributes the processing steps for handling received network packets across the available processor cores so that these can work in parallel from the protocol layer onwards. Which cores receive how much work can be determined using a bit mask that is controllable via Sysfs. RFS, together with other functions, is said to offer a software emulation of the multi-queue functionality found in network cards (NICs). However, in his commit comment, which also includes tips for practical use, Herbert said that this approach has its disadvantages. The developer also lists test results which confirm that, in some cases, the technology considerably increases network throughput.

RFS, the second technology, is based on the first and tries to assign the processing of layer 3 and 4 of the network protocol directly to the processor core which runs the userspace application that will eventually accept and process the network data. The kernel hacker gives a rough overview of how this is done in his commit comment in the source code management system. This comment also contains various test results which show that the throughput is increased a little further with RFS; the benchmark results also show considerably shorter latencies. Further details about these technologies can be found in an article about RPS and RFS on LWN.net.

Drivers

There have been some further advancements in terms of the network stack as well as with LAN and Wi-Fi hardware drivers:

LAN:

• The kernel now automatically loads module-compiled drivers for chips which handle the physical layer ("Ethernet PHYs") when the network driver needs them – users therefore no longer need to ensure manually that the PHY module is loaded before the MAC module.
• The be2net driver now supports Single Root I/O Virtualisation (SR-IOV), which is relevant for virtualisation – this means that it can provide virtual network cards which directly use guest systems, decreasing host loads and, in some cases, considerably improving network throughput.
• The e1000e driver for recent Gigabit network chips by Intel and the r8169 driver for Realtek Gigabit chips now offer basic features to support the runtime power-saving mechanisms of I/O devices introduced with 2.6.34. As explained in the commit comments, however, the power saving functions also need to be enabled via Sysfs to make the chips go into standby, for instance, when no network cable is connected.
• The bnx, bnx2x and forcedeth drivers now support the Generic Receive Offload (GRO) infrastructure introduced in 2.6.29.

Wi-Fi:

• Another new kernel addition is the ath9k_htc Wi-Fi driver for Wi-Fi hardware with Atheros AR7010 or AR9271 chip sets.
• The kernel now offers the orinoco_usb driver for the ageing Wi-Fi cards that use a USB chip in Agere's Orinoco series.
• An Adaptive Noise Immunity (ANI) implementation is designed to allow the ath5k driver suitable for older Atheros Wi-Fi chips to achieve higher transmission rates in high noise environments; in tests in such environments, the patch is said to have almost doubled the transmission rate.
• The rt2x00 driver's support of Ralink series Rt30xx chip sets, which are designed for USB or PCI, is now enabled by default, as this support is said to have reached a similar level of maturity to that of Rt28xx chips.
• Intel has discontinued its maintenance of the ipw2x00 drivers which address 802.11b Wi-Fi modules that were mainly integrated into first and second generation Centrino notebooks. However, this step by the Intel developers was criticised by network subsystem maintainer David Miller, who said that Intel not releasing any documentation about the Wi-Fi chips supported by these drivers will make it much harder to continue maintaining the drivers.

In the overview of the most important changes in his main Git-Pull request, David Miller highlights various further advancements – such as multiple multicast routing tables (1, 2, 3, 4), IPV6 bridge multicast snooping and port reservations. Also new is the support of the CAIF protocol developed by ST-Ericsson and used with modems (for example 1, 2, 3, documentation).

The kernel now also understands version 3 of the Layer 2 Tunnelling Protocol (L2TP) (for example 1, 2, 3, documentation). Sysfs now offers tagged directories, improving the network namespace-specific integration of the virtual Procfs and Sysfs file systems. These have also been extended in other kernel areas.

Next: Minor gems

1 2 next »