[Openswan dev] Small optimisation for lots of interfaces

[D. Hugh Redelmeier]

| From: David McCullough <davidm at snapgear.com>

| Firstly,  it not a PC,  its a 533MHz ARM Xscale router,  so that may be why
| it surprises you :-)

533MHz is faster than many machines that I've used for *swan.  But I
never tried as many tunnels.

Timing problems are often not constant factors (like CPU MHz) but
algoritmic complexity issues.

| It seems the ifconfig is the slow part (all kernel time too).

You've certainly demonstrated that.

Any idea why?  Do you have strace?  Maybe you can see if it is making
an ureasonable number of system calls.

I admit that this doesn't matter too much -- you already have a
solution.

| > I'd actually expect some of the code in Pluto for discovering
| > interfaces to be a worse problem when there are a lot of interfaces.
| 
| Absolutely,  I am sure it does.

| I would be interested in others experiences with large tunnel counts
| using OpenSwan.  I have run over 1000 simple tunnels between two hosts
| using freeswan (ie., single SA for all tunnels),  but pluto seems to get
| unstable with much over 200 truly independant tunnels.  Has any one else
| has this experience ?

[Caveat: I've not been working on Pluto's code for a couple of years.]

What do you mean by "unstable"?  Slow, I would expect.  Broken, not so
much.

Lots of places in Pluto use naive algorithms.  Ones that are linear in
the number of connections when something much faster is possible (eg.
sequential searches).  Sometimes quadratic or worse.  These have
generally not been problems.  When you get to larger tunnel counts,
this might well change.

This was a conscious choice.  "Premture optimization is the root of all
evil."  But when optimization is needed, it is time to do it.

The most infamous performance problem is in the startup scripts: n**2
in the number of connections.  Henry was going to fix the sh/awk/etc
script to make it linear but did not get done.  There are
work-arounds.  One is a C-based startup program that does not suffer
from this.

BTW, I'd be interested in a thumbnail description of a deployment that
uses so many tunnels.