Red Hat Bugzilla – Bug 155964
e1000 NICs break ECN
Last modified: 2007-11-30 17:11:04 EST
Description of problem: While debugging an unrelated problem today, I noticed that one of my machines was not negotiating ECN TCP connections. That is, for an outgoing connection, the initial TCP SYN packet didn't have the ECN/CWR bits set. For an incoming SYN/ECN/CWR packet, the reply packet was SYN/ACK instead of SYN/ACK/ECN. This was despite the fact that /proc/sys/net/ipv4/tcp_ecn was "1". Another machine running the same kernel, with exactly the same RPMs installed, and exactly the same /etc/sysctl.conf file, correctly attempted to negotiate ECN TCP connections. Another machine also running FC3 and the same kernel (but with only a minimal set of RPMs) also worked correctly. After much testing, the common thread seems to be this: the kernel fails to use ECN if the TCP connection being initiated is sent/received on an "Intel Corp. 82540EM Gigabit Ethernet Controller (rev 02)" NIC using the e1000 driver. (The "smoking gun" was being able to test a machine with two Ethernet interfaces (eth0 = epic100; eth1 = e1000). ECN on eth0 worked as expected but didn't work on eth1.) Version-Release number of selected component (if applicable): I'm encountering these ECN problems under both kernel-2.6.10-1.770_FC3 and kernel-2.6.11-1.14_FC3. How reproducible: Take a FC3 machine that contains an "Intel Corp. 82540EM Gigabit Ethernet Controller (rev 02)" NIC. Make sure that /proc/sys/net/ipv4/tcp_ecn is "1". Either initiate a new outbound TCP connection, or initiate a new inbound TCP connection from an ECN-enabled hosts. Actual results: The kernel will not attempt to negotiate ECN. Expected results: The kernel should attempt to negotiate ECN. Additional info: I ruled out the possibility that any of my iptables rules was using the ECN --ecn-tcp-remove target to strip the ECN bits.
No ethernet chip supporting TSO (TCP Segmentation Offload) supports ECN. If you want ECN back, disable TSO on the device by executing the command: bash# ethtool -K eth0 tso off See the ethtool man page for more details.
Ok, understood; thanks. Has the kernel only recently started supporting TSO? Or has TSO support been present for a while, but I just didn't notice it? Is there any good reason why NIC manufacturers couldn't support ECN in TSO, or have they simply not bothered?
TSO is present in all 2.6.x kernels. ECN isn't supported properly because the TSO driver interface the hw guys are building against is specified against Microsoft and it doesn't consider ECN bits at all.
That's unfortunate, but given that Microsoft doesn't seem to care about ECN at all (in either software or hardware), it makes sense. Thanks for the info.