Reducing the need to compile a custom kernel

[Volodymyr Kostyrko]

Jeremy Chadwick wrote:
> On Mon, Feb 13, 2012 at 05:05:41PM +0200, Volodymyr Kostyrko wrote:
>> Jeremy Chadwick wrote:
>>> I want to note here: the pf ALTQ options are a pain in the butt, quite
>>> honestly.  I've found in the past that removing the ones you don't use
>>> won't result in a successful build, thus one must include them all.  We
>>> do need ALTQ support though, for rate-limiting capability.  The NOPCC
>>> option is needed for SMP builds, which makes me wonder what the state of
>>> SMP is in this regard -- meaning, on non-SMP builds, is it still safe
>>> to include ALTQ_NOPCC?
>>
>> It seems like I'm missing something. What is good about using
>> non-SMP kernel?
>
> Nothing.  It's a question of whether or not use of ALTQ_NOPCC causes
> breakage on non-SMP kernels, or if FreeBSD even bothers to support
> non-SMP at this point.  "Non-SMP" means "without options SMP".

You got my point. I'm a single core user today but I run SMP-enabled kernel.

> Rephrased: if SMP is the default, and "options SMP" works just fine on
> systems without multiple processors/cores, then the ALTQ_NOPCC option
> should probably be removed.

Yep, works for me. However I had found some cruft about extra processing 
power which would be used in expense of correct work. Can this be 
something like IPFIREWALL_FORWARD that adds some latency to most cases 
providing some use only for chosen ones?

-- 
Sphinx of black quartz judge my vow.