lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 06 Apr 2011 13:02:39 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	acme@...stprotocols.net
Cc:	jesse.brandeburg@...il.com, fedora-kernel-list@...hat.com,
	netdev@...r.kernel.org, jesse.brandeburg@...el.com
Subject: Re: fedora 14 kernel performance with ip forwarding workload

From: Arnaldo Carvalho de Melo <acme@...stprotocols.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@...olle 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@...olle 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 :)

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ