[Openswan dev] ocf debian

[Harald Jenny]

On Thu, Dec 16, 2010 at 05:48:12PM -0500, Paul Wouters wrote:
> On Fri, 17 Dec 2010, David McCullough wrote:
> 
> [ bumping to Dev@ as well, to get more input]
> 
> I'll add some of this text to the wiki OCF docs. Thanks for explaining :)

Good idea :-)

> 
> >Yes,  but not on desktop systems without HW acceleration,  and that is what
> >we are talking about here I think,  so,  just disable it and move on IMO.
> 
> to elaborate a little on that, OCF would help to use multiple cores, but openssl
> and similar problems can do the same already using threads.

Ok

> 
> >>How does the speed compare?
> >
> >Thats pauls area at the moment.  I believe its faster than netkey,  but I
> >need to fix a dead lock before we can be truly sure ;-)
> 
> Yes please :) It's the only thing blocking openswan 2.6.33. No pressure :) :)

*ggg*

> 
> I've heard rumors that netkey can schedule an SA per CPU, so with multiple
> tunnels it might distribute the load. I have not confirmed this in a bench
> mark yet. We will put up our benchmarks once we can finish the runs without
> a crasher, but on a dual core machine we definitely see an increase in cpu
> usage, but we cannot tell yet what the speed increase vs additional overhead is.

Hmmm sounds very interesting...

> 
> >It should do.  Trouble is ipsec will not load without loading ocf.
> >
> >What might be nice is if we could somehow have ipsec.ko support both,
> >but only use "ocf" if it is loaded.
> >
> >I can see two way to do this.  One is by treating ocf like a dll,  checking
> >for symbols and using them if they exit.
> 
> I could ask Bart, as he implemented a system similar to this for the SAref
> hooks.

Well this would make IMHO very much sense.

> 
> >Or,  two ipsec.ko modules,  one with ocf support and one without.  The
> >correct one is selected at boot time.
> 
> No more calcgoo and multiple modules please :)

+1

> 
> >I actually think you would be better off with two packages.  A stock
> >openswan and an openswan+ocf,  that way you can select what you want up
> >front when you install,  and we don't need to create some weird hacky
> >thing to work around all the module dependancies etc.
> 
> That would work too.

Please not :-)

> 
> Btw even with ocf support in klips, it does not seem to autoload any of it
> if no ocf driver is found. It would be nice to load cryptosoft if we can't
> find any driver.

Maybe this should be done by ipsec startup scripts?

> 
> We could also try and have the initscripts look for OCF hardware and load the
> right driver. Or just trust the user to specify this in ipsec.conf and load
> it?

Hmmm I slowly come to the conclusion that we might remove the cryptoapi and
internal crypto code in favour of just OCF when this automatically uses the
cryptoapi code if no crypt-hardware is present...

> 
> Does the order of loading matter for klips? I don't think so, and I believe you
> can load/unload any OCF driver while the SA keeps running?

Oh that would be very cool.

> 
> Paul

Kind regards
Harald