[Openswan dev] ocf debian
harald at a-little-linux-box.at
Fri Dec 17 12:42:08 EST 2010
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.
> >>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 :) :)
> 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
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 :)
> >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
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.
More information about the Dev