lkml.org 
[lkml]   [2003]   [Dec]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Extremely slow network with e1000 & ip_conntrack
Harald Welte <laforge@netfilter.org> wrote:
>
> Well, the problem is certainly triggered by connection tracking.

Thanks for the reply, and for forwarding to lkml.

To recap for lkml (I do not subscribe to lkml, so please CC either me or
netfilter-devel):

e1000 becomes extremely slow for traffic generated from the box. I
tested by issuing an ftp from another box and doing a "get", but other
kind of traffic (scp, samba) are similarly affected. The speed drops to
~40kbps. This happens when ip_conntrack is loaded, even with no rule in
the tables. Unloading the module makes the speed recover, but I'd like
to make use of state tracking.

There is no change in the "put" direction. I didn't notice any change
in speed of traffic routed through the box, though I did not test that
case sufficiently.

This bug does not appear on all chips supported by the driver. Please
see previous email for the 2 cases I tested.

> If I understood correctly:
>
> 1) stock 2.5.43: OK
> 2) stock 2.5.44: PROBLEM
> 3) stock 2.5.44 with the driver from 2.5.43: PROBLEM
> 4) stock 2.5.44 with ip_conntrack.o from 2.5.43: PROBLEM

Correct. The problem exists still on 2.6.0-test11.

> So it has to be a change outside of the e1000 driver and outside of the
> connection tracking code.
>
> In the meantime, I think taking the discussion back to lkml seems to be
> a good idea - since neither e1000 nor ip_conntrack code seem to be the
> direct cause of the problem.

After lots of trial-and-error, I can make the problem disappear by
backing these 4 files out from 2.5.44 to their 2.5.43 versions.

net/ipv4/icmp.c
net/ipv4/ip_output.c
net/ipv4/raw.c
net/ipv4/udp.c

Note that in both cases I needed to #include <linux/netfilter_ipv4.h>
rather than <linux/netfilter.h> in net/ipv4/raw.c to get it to compile.

I have attached my .config, though note that I have reproduced the
problem on another motherboard also (intel P4 on 865G running
2.6.0-test11).

gcc 3.3.2 was used on the P3 box and 3.2.1 was used on the P4 box.

Regards,
Stephen
[unhandled content-type:application/octet-stream]
\
 
 \ /
  Last update: 2005-03-22 13:59    [W:0.030 / U:4.108 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site