Re: Performance issue due to constant "modprobes"

[Ed W <lists@wildgooses.com>]

On 14/04/2011 08:13, Maciej Żenczykowski wrote:
> Note that: -M '' is -M followed by a space and two single quotes.
> 
> Furthermore, note that with -M '', you will want to modprobe ip_tables
> or modprobe ip6_tables manually first at system startup (or build them
> into the kernel), since those modules don't autoload (hence why
> iptables tries to load them).
> 
> I wonder if there's an easy way iptables userspace could detect
> whether these modules are already loaded (or compiled into the
> kernel), and not even try to load them, if so...
> 

OK, using kernel 2.6.38 (previously on .37) iptables 1.4.10 patched with
the delayed module loading commit, then I still get something like 20
attempts to "modprobe iptables -q" when I start up a near vanilla
shorewall script (I just entered enough info that it boots up with a
couple of basic zones).

If I just do an iptables restore, or a near equivalent "shorewall
restore" then I get just a single modprobe iptables -q.

This suggests that the shorewall start tickles several iptables calls.
Each call causing one modprobe


Now this seems to be coming from the iptables.c modprobe call.
Annoyingly this didn't seem to be happening when I used kernel 2.6.37.
It's timeconsuming to reload kernel changes to this embedded device, but
I will check back and confirm this is a change in behaviour between kernels.

However, it seems unexpected that there are any calls from iptables
since it does some kind of test before calling modprobe?  I'm sure I
didn't get any on .37??!  Any insights on why I get even a single
modprobe call given everything built in kernel and a static iptables binary?

Thanks

Ed W

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