Kernel Log - Coming in 3.6 (Part 2): Networking
by Thorsten Leemhuis
Smaller buffers are designed to help avoid bufferbloat. "TCP Fast Open" promises to speed up HTTP connections. The netfilter infrastructure can now use userspace programs to help with connection tracking.
The TCP Small Queues (TSQ) feature makes Linux 3.6 use small buffers of no more than 128KB per network socket by default. Like various other recent kernel modifications, this measure is designed to avoid bufferbloat, a term used for problems such as high network latencies and disrupted connections caused by too much buffering during data transfers. According to test results provided by the responsible developer, the smaller buffers per socket don't affect data throughput; if required, administrators can use the /proc/sys/net/ipv4/tcp_limit_output_bytes proc file to adjust the value at runtime.
The kernel now includes client-side support for TCP Fast Open (TFO) (1, 2, 3, 4, 5); server-side support is planned to follow in Linux 3.7. TFO is an experimental TCP extension that has not yet been approved by the Internet Assigned Numbers Authority (IANA). It is designed to reduce the overhead when establishing a connection by making clients request data when initiating a TCP connection, in case the server and client have already communicated. This combines the first two steps of the previously used "TCP three-way handshake" into one and is supposed to speed up HTTP connections. Further information on this technology is available in the article "TCP Fast Open: expediting web services" on LWN.net.
The bnx2x driver, which handles various Ethernet chips from Broadcom, now supports the Energy-Efficient Ethernet (EEE) standard that is specified in IEEE 802.3az; the stmmac driver for embedded Ethernet cores by STMicro is now also capable of using these technologies for configuring the hardware parameters that influence the power consumption of Ethernet chips. Users can read or set EEE parameters via the recently released ethtool 3.5.
The r8169 Ethernet driver now supports Realtek's RTL8168G and RTL8106E Ethernet chips. The team driver now offers a broadcast mode that allows it to send all packets via all suitable ports. The rt2800pci Wi-Fi driver now supports Ralink's RF5360 and RT5392 chips; it also includes new experimental support for the RT3290 family of Wi-Fi chips.
Current state of development
Last weekend, Linus Torvalds released the fourth release candidate of Linux 3.6. Torvalds notes that things have been rather quiet; he said that this is probably due to numerous kernel developers having attended the recent conferences in San Diego.
The netfilter infrastructure that is used for firewalls can now access helper programs that operate in userspace for connection tracking. This is supposed to ease the development of very specific helpers that are likely not to be accepted for mainline inclusion in the form of kernel-space connection tracking helpers.
The new Virtual Tunnel Interface (VTI) enables Linux 3.6 to tunnel IPSEC data streams.
Various modifications contributed by Volkswagen employee Oliver Hartkopp allow Linux to support CAN FD (CAN with Flexible Data-rate) – a Bosch-sponsored extension to the Fieldbus CAN (Controller Area Network) which is mainly used in cars and industrial system control. More information on this extension and its Linux support is available in an article in the CAN newsletter. Another new addition is the support for ematch-based traffic shaping for CAN messages, which is also sponsored by Volkswagen. This code is designed to help alleviate problems that can occur when multiple users write to the CAN bus simultaneously; find details in a study entitled "SocketCAN and queuing disciplines" and in the "CAN frame traffic shaping" section of a document in which Hartkopp describes the Linux CAN support.
David Miller, the maintainer of the network code, explains various other changes in the email he sent with his main Linux 3.6 git pull request. Among them is the removal of the routing cache that has been in preparation for some time; apparently, the routing cache was vulnerable to a denial-of-service (DoS) attack.