netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Harald Welte <laforge@netfilter.org>
To: ookhoi@humilis.net
Cc: linux-kernel@vger.kernel.org, netdev@oss.sgi.com,
	Netfilter Development Mailinglist
	<netfilter-devel@lists.netfilter.org>
Subject: Re: why does netfilter make upload very slow? (was: Re: e1000 -> 82540EM on linux 2.6.0-test[45] very slow in one direction)
Date: Wed, 8 Oct 2003 17:32:37 +0200	[thread overview]
Message-ID: <20031008153237.GC25743@sunbeam.de.gnumonks.org> (raw)
In-Reply-To: <20031008131320.GD16964@favonius>

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

On Wed, Oct 08, 2003 at 03:13:20PM +0200, ookhoi@humilis.net wrote:
> # > I have netfilter enabled, and will try another -test6 kernel with
> # > netfilter not compiled in to see if that indeed makes a difference.
> # 
> # I can confirm now that disabling netfilter in 2.6.0-test6 makes the nic
> # perform oke wrt upload.
> # I (just like Florian) had no iptables rules active in the former
> # 2.6.0-test6 kernel, but netfilter was compiled in.
> 
> Would somebody like to explain why netfilter (in kernel, but not in use)
> makes upload go very slow? I am by no means a network guru, but eager to
> learn :-)

let's get this straight.  There are five possible cases

a) CONFIG_NETFILTER disabled.  you won't even have the netfilter hooks
   in the network stack (so certainly no netfilter-using modules loaded)
b) CONFIG_NETFILTER enabled, but _no_ modules (iptable_filter,
   ip_conntrack, ...) attached to the netfilter hook
c) CONFIG_NETFILTER enabled and iptable_filter.o (which pulls ip_tables.o)
   loaded, NO RULES in the table
d) CONFIG_NETFILTER enabled and iptable_filter.o (which pulls ip_tables.o)
   loaded, RULES in the table
e) CONFIG_NETFILTER enabled and ip_conntrack.o loaded, iptable_filter
   loaded or not, rules or not

So if you want to give us an idea about where the bottleneck might be,
please clearly indicate between which of the two cases you see this
performance penalty. 

This way we can isolate the culprit.

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

  parent reply	other threads:[~2003-10-08 15:32 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-10-08 13:13 why does netfilter make upload very slow? (was: Re: e1000 -> 82540EM on linux 2.6.0-test[45] very slow in one direction) ookhoi
2003-10-08 14:54 ` David S. Miller
2003-10-08 15:32 ` Harald Welte [this message]
2003-10-15  8:28   ` Florian Zwoch
2003-10-15  9:48     ` Harald Welte

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20031008153237.GC25743@sunbeam.de.gnumonks.org \
    --to=laforge@netfilter.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@oss.sgi.com \
    --cc=netfilter-devel@lists.netfilter.org \
    --cc=ookhoi@humilis.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).