Date:        Mon, 20 Feb 2006 10:53:00 -0800
    From:        jonathan@dsg.stanford.edu
    Message-ID:  <E1FBG9e-0006HT-00@smeg.dsg.stanford.edu>

  | But even if you don't use IPsec *at all*, turning on IPsec imposes a
  | significant packet-classification on all traffic (except for outbound
  | TCP traffic on connected sockets). Even inbound TCP incurs a
  | significant penalty, which is easily measurable on network benchmarks.

I can easily believe this, and this is the kind of response I was
looking for in my original query (I was not looking for starting a
debate on LKMs - I really had not imagined LKMs for IPSEC purposes).

[Aside: I know you're not the only, or first, person to have made
this comment, I chose your message to reply to because of other
comments you made.]

What I'd prefer to know though is what "measureable" means, and how
that affects GENERIC.   That is, I don't really care much if a GENERIC
kernel isn't suitable for your research - and I really doubt that
you do either.   If you want IPSEC (or the KAME IPSEC) disabled, you
know how to make that happen...

I know you described how to measure the performance drop, I'd do it,
except that I don't think I have any systems with the necessary
characteristics (they're all so much faster than the network interfaces
that an extra 100% packet processing cost is barely going to be noticed,
I have nothing with 10G interfaces, and nothing connected to a 1G
interface that's on a switch capable of actually forwarding at Gb
rates...)

However, I can interpret the results before knowing what they are.
That is, for a system, that can just forward packets at N pps,
then for generic purposes, if enabling IPSEC (as it is now
implemented, the KAME version) reduces the handling rate to 0.8 * N
I wouldn't mind in the slightest.   (Much) More than that as a reduction
and then I'd be more concerned about having IPSEC on by default,
but it would probably have to reduce to closer to 0.5*N before I'd
be convinced that IPSEC on by default was impossible..

The vast majority of systems never see packet loads anything like
their potential maximum, and a slight slowdown in processing time
wouldn't bother me in the default kernel.   Those using the system
for applications where every last cycle is crucial can certainly
remove anything they don't need (and also quite likely, omptimise
for the particular processor they're running on).

Actually that raises a comparison question ... compiling kernels
that support all the versions of x86 processors, or sparc processors
(and probably others where one kernel supports a processor family)
has a bunch of costs, as the low level code needs to be constantly
checking which processor is currently being used to select the
correct code path.    How does the IPSEC cost compare to that cost?

I know this is going to be not something easy to measure, as
the two are in largely unrelated parts of the kernel, but people
must have some feel (10% extra processing, 20%, ...)

Aside: and relating to comments in other messages on that
other topic - I don't run GENERIC kernels, I don't care what
options are in them for my own personal use, and I'm not
suggesting that IPSEC be enabled (or asking why it isn't)
in order to avoid needing to compile my own personal kernel.

I'm more concerned with the message it sends - options that
come commented out (disabled) in GENERIC is generally sending
a message that most probably that isn't something that people
really want to have enabled in their systems.  On the other
hand, options that are enabled send the message that "this
is here and available, use it if you want, or disable it to
save space and time".   I'd kind of prefer that IPSEC send
the 2nd kind of message.

That is, providing that NetBSD's implementation (currently
that means the KAME implementation) is really up to scratch
for the purpose.   If it isn't, then that is the answer to
my original question.

  | Either way, I find the results extremely discouraging.

How much does it take to discourage you?    I tend to have IPSEC
enabled on my systems (used occasionally, though not often), and
have never been bothered by network performance.   But nor am I
trying to get the max possible (I even tend to just keep on using
802.11b instead of plugging in 100baseTX fdx, even when I have the
cable sitting on my desk - just because converting between the
two is currently not seamless, and 802.11b performance is just
fine for me...)

  | Quite.  But speaking just personally, I'm more interested in adding
  | /etc/rc.d hooks to not enable utterly useless protocols[*] like
  | IPv6 on my machines, than I am in adding IPv6 support to FAST_IPSEC :-/.

For what it is worth, which is very little, I have some students
(undergrad project, so don't expect much) working on a way to really
dynamically remove protocols, while the system is running.   After
the knob is turned, IPv6 (or whatever) would (almost) appear as if
it wasn't compiled into the kernel (except probably for connections
already using the protocol - and that would be TCP only).  No new
sockets, no new incoming connections to listening sockets, and stuff like
examining the interface address lists, routing tables (from outside
the kernel) would simply not see the disabled protocol at all.

Or that's what I am hoping for ... it will be a year from now before
they've accomplished anything - assuming they ever get anything
that would be useful.

  | [*] That is, IPv6 is utterly useless on *my* machines.

You can't just remove "options INET6" from your kernels?

That sounds as if it would solve your immediate problem more
easily than either a "don't bother configuring" or a "remove
this protocol" mechanism in a kernel that had INET6 included.

kre