Subject: Re: IPSEC in GENERIC
To: None <tech-kern@netbsd.org>
From: Michael van Elst <mlelstv@serpens.de>
List: tech-kern
Date: 02/20/2006 23:52:40
jonathan@dsg.stanford.edu writes:

>If I don't want to run IPv4, I don't have to build a special kernel;
>GENERIC plus our boot-time /etc/rc.conf mechanisms can do that just
>fine.  So, why should it be any different if I want to run lPv4, but
>not IPv6?

There is no necessity to have it different. But it is different.


>Whether or not *you* think it's trivial for me to build a custom
>kernel, just to disable a feature which is of no use to me (and might
>even be harmful), is besides the point.

Maybe besides your point, but it is completely on topic unless
you can disable IPSEC with our boot-time /etc/rc.conf mechanism.

So far we need a special kernel to do IPSEC and we need a special
kernel to remove IPv6.


>>Let me rephrase this with the words in my argument to make sure that
>>I understand your words correctly.
>Let me go through those (apparently deliberate and inflammatory)
>misunderstandings one by one:

Interesting...


>>Making a GENERIC kernel support IPSEC initially is bad.
>No, I never said that, so please don't put words in my mouth like
>that. There's nothing wrong with supporting IPsec, *provided* doing
>so doesn't impair other uses.  Unfortunately, as far as we know,
>currently IPsec does impair other uses.

Now that language is not simple enough for me. But your conclusion
is that, as far as we know, putting IPSEC in GENERIC is bad.


>>Making a GENERIC kernel for people useful that rely on the initial install is 
>>bad.

>Hah!  Michael, do you realize you've just contradicted your own
>argument?  A kernel with IPv6 support is not useful for *me*, but you
>claim that's not worth fixing because I can easily build my own
>kernel. But so can anyone else. So by your own argument, what is (or
>isn't, in UGENERIC) is beside the point, right?

You can build your own kernel but "people that rely on the initial install"
obviously cannot. Your conclusion that anyone else has your abilities is wrong.



>>Making a GENERIC kernel as versatile as possible for newcomers is bad.
>Indeed.  But versatility is in the eye of the beholder.

So you agree that I understood you correctly.


>>Making a GENERIC kernel that spoils benchmarks is bad.

>Yes, that's the consensus of the developers who've been maintaining
>portions of the stack.  Not just me, but (if I recall correclty)
>Thor, and Jason Thorpe, and others.  I'm not sure if Matt Thomas
>commented or not.

Apparently having GENERIC tuned to certain benchmarks is not
on my priority list :)


>>And that is supported by several senior NetBSD developers.

>Yes. In fact, more than that: there was a *consensus* not to turn on
>IPsec in GENERIC kernels, on the understanding IPsec would cause a
>noticeable performance hit.

Yes, I remember this dicussion. I wouldn't call it a *consensus*
but I guess that this is in the eye of the beholder. Back then
I might even have agreed, but now I think it is the wrong decision.


>As far as I can see, *you* want IPsec, you don't care about the impact
>of IPsec on other users.

Putting words in other peoples mouth? You? :)

No, Jonathan. Otherwise I wouldn't care if building kernels is
easy for you. For me the impact of having IPSEC in GENERIC is small
and so it is for you.


> That's not a very productive way to reach
>your goal.

I have many goals, forcing some decision on the contents of GENERIC
isn't among them. But I like to participate in the discussion, in
case other people without a focus on benchmarks agree with me. We
even might have a *consensus* on what GENERIC should be. But even
when there is no such *consensus* or even a decision, I wouldn't
just start to agree with the majority or the decision makers.


> OTOH, if you *do* want to do something productive, why
>don't you try to quantify the actual, current impact of IPsec, via the
>techniques I've outlined earlier?

I am currently more concerned about some weird TCP behaviour that makes
my backup crawl. Oh yes, and the abysmally slow NFS when used together
with null mounts. The read-before-write behaviour of our filesystems
is a problem too.

The impact of the IPSEC option on a system that doesn't use IPSEC
is difficult to measure. I only have a 100Mbps network and see nothing
and the bge driver probably has issues that impact performance much
more than the IPSEC option. What about FAST_IPSEC? It is of no use
to me because it doesn't support IPv6.

-- 
-- 
                                Michael van Elst
Internet: mlelstv@serpens.de
                                "A potential Snark may lurk in every tree."