Re: why does netfilter make upload very slow? (was: Re: e1000 -> 82540EM on linux 2.6.0-test[45] very slow in one direction)

[Harald Welte <laforge@netfilter.org>]

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

Hi Florian!

I'm Cc'ing all the mailinglists in order to keep them posted about the
question you've raised there.  All further discussion will move to
netfilter-devel, so for those interested: Please continue there.

On Wed, Oct 15, 2003 at 10:28:50AM +0200, Florian Zwoch wrote:
> >a) CONFIG_NETFILTER disabled.  you won't even have the netfilter hooks
> >   in the network stack (so certainly no netfilter-using modules loaded)
> no problem
> 
> >b) CONFIG_NETFILTER enabled, but _no_ modules (iptable_filter,
> >   ip_conntrack, ...) attached to the netfilter hook
> no problem
> 
> >c) CONFIG_NETFILTER enabled and iptable_filter.o (which pulls ip_tables.o)
> >   loaded, NO RULES in the table
> no problem
> 
> >d) CONFIG_NETFILTER enabled and iptable_filter.o (which pulls ip_tables.o)
> >   loaded, RULES in the table
> no problem (as long as i dont load any rules that require ip_conntrack)
> 
> >e) CONFIG_NETFILTER enabled and ip_conntrack.o loaded, iptable_filter
> >   loaded or not, rules or not
> *boink*

So It's clearly the connection tracking subsystem.  This is on one hand
good (because it means it's neither netfilter nor iptables).  

> whenever i try to load ip_conntrack the nic performance drops from 5mb/s 
> to 200k/s.

On the other hand, this is definitely way worse than you would expect.
Can you please tell me more information about:

- number of connections you have? (cat /proc/net/ip_conntrack | wc -l)
- number of buckets and ip_conntrack_max (printed at ip_conntrack
  loadtime
- your traffic pattern.  Are you spraying udp packets with random
  src/dst? What kind of connections (protocol, application) are you
  testing with?
- what about the hardware (cpu, memory, smp?)

Even the worst tests we've had so far (random UDP packets) 'only'
reduced the througput by about 50%.   Maybe we can do better than 50%
worst case behaviour, but you will always observe a visible impact as
soon as you start connection tracking for every single packet (which is
what 'insmod ip_conntrack' implies).

> still using 2.6.0-test6.

Have you observed this behaviour with other kernel versions?  Was there
a performance change between 2.4 and 2.6?  Or did you always observe
this grave performance loss?

> regards,
> Florian

-- 
- 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 --]