From: David Miller <davem@davemloft.net>
To: acme@ghostprotocols.net
Cc: jesse.brandeburg@gmail.com, fedora-kernel-list@redhat.com,
netdev@vger.kernel.org, jesse.brandeburg@intel.com
Subject: Re: fedora 14 kernel performance with ip forwarding workload
Date: Wed, 06 Apr 2011 13:02:39 -0700 (PDT) [thread overview]
Message-ID: <20110406.130239.232756965.davem@davemloft.net> (raw)
In-Reply-To: <20110406195719.GE14697@ghostprotocols.net>
From: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
Date: Wed, 6 Apr 2011 16:57:19 -0300
> Something like ftrace code changing when the user inserts the first
> rule?
>
> People wanting top performance disable it in the build, but thos wanting
> to stick to vendor provided kernels don't have that choice :)
Using ftrace-like stubs would be an interesting idea, and I highly encourage
people to work on something like that.
However I want to reiterate that I think that real rules are installed
in Jesse's case, and once he removes those the majority of the
overhead will disappear. The FC14 workstation I'm using right now, on
which I've made no modifications to the installer's netfilter settings,
has the following rules:
--------------------
[root@ilbolle davem]# iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT icmp -- anywhere anywhere
ACCEPT all -- anywhere anywhere
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:ssh
ACCEPT udp -- anywhere anywhere state NEW udp dpt:ipp
ACCEPT udp -- anywhere 224.0.0.251 state NEW udp dpt:mdns
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:ipp
ACCEPT udp -- anywhere anywhere state NEW udp dpt:ipp
REJECT all -- anywhere anywhere reject-with icmp-host-prohibited
Chain FORWARD (policy ACCEPT)
target prot opt source destination
REJECT all -- anywhere anywhere reject-with icmp-host-prohibited
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
[root@ilbolle davem]#
--------------------
I suspect Jesse has something similar on his test box.
When no rules are loaded, all the stubs make happen is a function call
plus a list_empty() check. Nothing more. I really can't see that, all
by itself, obliterating routing performance.
In fact I've done udp flood tests, as recently as a month ago, with just
NETFILTER=y and no rules installed, and the impact was minimal.
And that was on sparc64 where function calls are expensive :)
next prev parent reply other threads:[~2011-04-06 20:03 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-06 18:51 fedora 14 kernel performance with ip forwarding workload Jesse Brandeburg
2011-04-06 19:12 ` David Miller
2011-04-06 19:57 ` Arnaldo Carvalho de Melo
2011-04-06 20:02 ` David Miller [this message]
[not found] ` <20110406.130239.232756965.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
2011-04-06 20:13 ` Arnaldo Carvalho de Melo
2011-04-06 20:18 ` Eric Dumazet
2011-04-06 20:29 ` David Miller
2011-04-06 20:32 ` Eric Dumazet
2011-04-06 21:08 ` Brandeburg, Jesse
2011-04-06 21:11 ` Eric Dumazet
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=20110406.130239.232756965.davem@davemloft.net \
--to=davem@davemloft.net \
--cc=acme@ghostprotocols.net \
--cc=fedora-kernel-list@redhat.com \
--cc=jesse.brandeburg@gmail.com \
--cc=jesse.brandeburg@intel.com \
--cc=netdev@vger.kernel.org \
/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).