Bug 155964 - e1000 NICs break ECN
e1000 NICs break ECN
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
3
All Linux
medium Severity medium
: ---
: ---
Assigned To: David Miller
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-04-26 04:57 EDT by James Ralston
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-04-26 18:57:54 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description James Ralston 2005-04-26 04:57:54 EDT
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.
Comment 1 David Miller 2005-04-26 18:57:54 EDT
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.
Comment 2 James Ralston 2005-04-29 17:03:05 EDT
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?
Comment 3 David Miller 2005-04-29 17:11:43 EDT
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.
Comment 4 James Ralston 2005-04-29 19:27:41 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.