On 2/14/12 7:43 AM, Ian Smith wrote:
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)
well it's not that big but you will be running extra code for every
packet unless you want it.
when I made it an option but I was mainly trying to placate the "just
say no" crowd.
I perswonally wouldn't mind having it on by default in GENERIC, as
long as we still make it an option
so people who want every last drop of cpu can remove it.
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
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
