Thread (5 messages) flat view 5 messages, 4 authors, 2003-10-15

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

From: Harald Welte <hidden>
Date: 2003-10-15 10:08:16
Also in: lkml, netfilter-devel

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:
quoted
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
quoted
b) CONFIG_NETFILTER enabled, but _no_ modules (iptable_filter,
  ip_conntrack, ...) attached to the netfilter hook
no problem
quoted
c) CONFIG_NETFILTER enabled and iptable_filter.o (which pulls ip_tables.o)
  loaded, NO RULES in the table
no problem
quoted
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)
quoted
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 [off-list ref]             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

Attachments

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help