From: Arnaldo Carvalho de Melo <acme@xxxxxxxxxxxxxxxxxx> 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 :) _______________________________________________ kernel mailing list kernel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/kernel