Date: Wed, 15 Feb 2012 02:43:49 +1100 (EST) From: Ian Smith <smithi@nimnet.asn.au> To: Alexander Leidinger <Alexander@Leidinger.net> Cc: julian@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Custom kernel poll summary (was: Re: Reducing the need to compile a custom kernel) Message-ID: <20120215014738.O95093@sola.nimnet.asn.au> In-Reply-To: <20120214123755.Horde.WkLNcJjmRSRPOkeTw7bUClA@webmail.leidinger.net> References: <20120210145604.Horde.ewjpSpjmRSRPNSH0YRHxgAk@webmail.leidinger.net> <20120214123755.Horde.WkLNcJjmRSRPOkeTw7bUClA@webmail.leidinger.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 14 Feb 2012 2:37:55 +0100, Alexander Leidinger wrote:
> Here is what I got, the first column is the number of requests, the second
> what is requested, and the 3rd my comments (basically it means, if there is a
> comment, it is not needed/possible to include in a modular kernel):
> ---snip---
[..]
> 1 IPFIREWALL_FORWARD -> performance impact too big if unused (julian)
I expect Julian will object if I've mis-paraphrased or over-simplified
something I recall him saying at least a couple of years ago :)
[..]
> 4 ALTQ* -> does add code to the pf module
> other impact?
ipfw(8) can also apply ALTQ tags, but relies on pfctl(8) to setup the
queues - or so I read; I've not used it here. From altq(4):
ALTQ Enable ALTQ.
ALTQ_CBQ Build the ``Class Based Queuing'' discipline.
ALTQ_RED Build the ``Random Early Detection'' extension.
ALTQ_RIO Build ``Random Early Drop'' for input and output.
ALTQ_HFSC Build the ``Hierarchical Packet Scheduler'' discipline.
ALTQ_CDNR Build the traffic conditioner. This option is meaningless at
the moment as the conditioner is not used by any of the
available disciplines or consumers.
ALTQ_PRIQ Build the ``Priority Queuing'' discipline.
ALTQ_NOPCC Required if the TSC is unusable.
ALTQ_DEBUG Enable additional debugging facilities.
Note that ALTQ-disciplines cannot be loaded as kernel modules. In order
to use a certain discipline you have to build it into a custom kernel.
The pf(4) interface, that is required for the configuration process of
ALTQ can be loaded as a module.
So which disciplines would one choose? Seeming an unlikely candidate?
> 1 IPSTEALTH -> changes ipfw module only?
I don't think this is specific to ipfw. From /sys/conf/NOTES:
# IPSTEALTH enables code to support stealth forwarding (i.e., forwarding
# packets without touching the TTL). This can be useful to hide firewalls
# from traceroute and similar tools.
But can it be disabled once added to kernel? It's no good as a default.
> 1 IPFIREWALL_VERBOSE_LIMIT=5 -> changes ipfw module only?
> loader tunable?
> 1 IPFIREWALL_VERBOSE -> changes ipfw module only?
> loader tunable?
sysctl.conf: net.inet.ip.fw.verbose and net.inet.ip.fw.verbose_limit
cheers, Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120215014738.O95093>