Re: Extremely slow network with e1000 & ip_conntrack

[Harald Welte <laforge@netfilter.org>]

[-- Attachment #1: Type: text/plain, Size: 2117 bytes --]

On Sun, Nov 30, 2003 at 07:54:15AM +0900, Stephen Lee wrote:
> Stephen Lee <mukansai@emailplus.org> wrote:
> > 
> > I compiled lots of kernels :-( and narrowed it down to between 2.5.26
> > and 2.5.46.
> > 
> > Kernel version	Chip		Problem?
> > 2.4.22		82540EM		N
> > 2.5.26		82540EM		N
> > 2.5.46		82540EM		Y
> > 2.6.0-test10		82540EM		Y
> > 2.6.0-test11		82540EM		Y
> > 2.6.0-test11		82547EI		N
> > 2.4.22nptlsmp		82547EI		N
> 
> I narrowed it down to patch-2.5.44.  e1000 is updated, but I backed out
> the driver to the 2.5.43 version and it didn't fix the problem. 
> Besides, 2.4.23 has a newer version of the driver and it doesn't have
> this problem.
> 
> As far as I see netfilter was not updated in that patch, was it? I tried
> insmod -f ip_conntrack.o from 2.5.43 into the 2.5.44 kernel and it
> didn't stop the problem from happening, either.
> 
> Please advice.  If you don't think this is a netfilter problem I'll go
> check with linux-kernel.

Well, the problem is certainly triggered by connection tracking.  

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

So it has to be a change outside of the e1000 driver and outside of the
connection tracking code.

Unfortunately I don't have a 2.5.44.patch right here on my notebook atm
(travelling to India). I'll download it at the next opportunity and try
to review which change could be the culprit.

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.

> Regards,
> Stephen

-- 
- Harald Welte <laforge@netfilter.org>             http://www.netfilter.org/
============================================================================
  "Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed."                    -- Paul Vixie

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]