[Openswan dev] ocf debian

[Harald Jenny]

On Fri, Dec 17, 2010 at 09:00:33AM +1000, David McCullough wrote:
> 
> Jivin Paul Wouters lays it down ...
> > 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 :)
> > 
> > > 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.
> 
> 
> on the "server and desktop x86 systems" we are focussing on at the moment ;-)

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 :) :)
> 
> 
> Yeah,  well,  no electricity for 2 nights in a row and a christmas party
> yesterday haven't helped either :-(

Hmmmm hope you find time soon

> 
> 
> > 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.
> 
> 
> Yep,  things are never as simple as they should be :-)

*ggg*

> 
> 
> > > 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.
> > 
> > > 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 :)
> > 
> > > 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.
> > 
> > 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.
> 
> Yes,  I did this on my ubuntu system in /etc/modprobe.d/ocf-cryptosoft.conf:
> 
> 	# face it,  we usually want at least one driver loaded :-)
> 	install ocf /sbin/modprobe --ignore-install ocf; sleep 2; /sbin/modprobe cryptosoft

Hmmm IMHO this should be done by openswan.

> 
> As far as I go,  you can always load cryptosoft (unless you want to stop
> klips from using OCF and fall back to something else,  thne you need to
> unload cryptosoft,  which can be done at any time).

Well if we focus on minimizing the crypto code I would vote for OCF...

> 
> > 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?
> > 
> > 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?
> 
> Yes,  if a driver gets removed the SA will be migrated,  or at least it
> should be.

Could somebody test this?

> 
> Order doesn't matter,  OCF selects HW over SW if there is a choice.

Sounds logic.

> 
> I don't think anything is needed in ipsec.conf.

I think if we decide to go with OCF which on all but hardware-accelerated
systems uses cryptoapi we would have a deterministic behavior which wouldn't
need any options.

> 
> Cheers,
> Davidm

Kind regards
Harald

> 
> -- 
> David McCullough,      david_mccullough at mcafee.com,  Ph:+61 734352815
> McAfee - SnapGear      http://www.mcafee.com         http://www.uCdot.org