From owner-freebsd-stable@FreeBSD.ORG Tue Feb 14 15:43:53 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F1672106566B for ; Tue, 14 Feb 2012 15:43:53 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) by mx1.freebsd.org (Postfix) with ESMTP id 4A2E48FC08 for ; Tue, 14 Feb 2012 15:43:52 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id q1EFhnTw014509; Wed, 15 Feb 2012 02:43:50 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Wed, 15 Feb 2012 02:43:49 +1100 (EST) From: Ian Smith To: Alexander Leidinger In-Reply-To: <20120214123755.Horde.WkLNcJjmRSRPOkeTw7bUClA@webmail.leidinger.net> Message-ID: <20120215014738.O95093@sola.nimnet.asn.au> References: <20120210145604.Horde.ewjpSpjmRSRPNSH0YRHxgAk@webmail.leidinger.net> <20120214123755.Horde.WkLNcJjmRSRPOkeTw7bUClA@webmail.leidinger.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: julian@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Custom kernel poll summary (was: Re: Reducing the need to compile a custom kernel) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 15:43:54 -0000 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