Date: Tue, 14 Feb 2012 08:43:10 -0800 From: Julian Elischer <julian@freebsd.org> To: Ian Smith <smithi@nimnet.asn.au> Cc: Alexander Leidinger <Alexander@Leidinger.net>, freebsd-stable@freebsd.org Subject: Re: Custom kernel poll summary Message-ID: <4F3A8F1E.8010402@freebsd.org> In-Reply-To: <20120215014738.O95093@sola.nimnet.asn.au> References: <20120210145604.Horde.ewjpSpjmRSRPNSH0YRHxgAk@webmail.leidinger.net> <20120214123755.Horde.WkLNcJjmRSRPOkeTw7bUClA@webmail.leidinger.net> <20120215014738.O95093@sola.nimnet.asn.au>
next in thread | previous in thread | raw e-mail | index | archive | help
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 >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4F3A8F1E.8010402>