IPsec performance

[Thor Lancelot Simon]

With 466MHz Celeron CPUs and decent network hardware (3c905B) the most
throughput I seem to be able to force through our IPsec is about 1.5MB/sec
(that's mega *bytes*, not bits). Though I'm told by several people that
this is not atypical for a software-only IPsec implementation, I don't
understand _why_.

I am using ESP only, with blowfish-CBC and no message digest. The
"bfspeed" test program from the OpenSSL library, with the library's
blowfish compiled to *not* use any of the asm or funky compiler flags
(that is, pretty much the exact code that's in the kernel's blowfish,
compiled with the same flags) can do 9.18 MB/sec in CBC mode on this
exact same hardware.

I don't understand where the 6X difference in performance is coming
from. I would suspect cache effects but I think we're actually spending
most our time *not* encrypting -- if it were just that the cipher ran
much slower because the cache were being thrashed, I wouldn't expect
the machine to be spending most of its time in the idle loop, which it is;
I'd expect a huge increase in "sys" time during an IPsec transfer.

Interestingly, it's *also* not some kind of lockstep with the receiver;
two streams run as slowly as one.

Yes, I can buy a hardware crypto card and port the OpenBSD drivers. But
given the actual cipher performance, I don't see why I should expect any
improvement. Has anyone got an idea what's going on here?

--
Thor Lancelot Simon t...@rek.tjls.com
"And where do all these highways go, now that we are free?"

[Ignatios Souvatzis]

On Wed, Jul 19, 2000 at 06:24:05AM +0900, ito...@iijlab.net wrote:
>
> >With 466MHz Celeron CPUs and decent network hardware (3c905B) the most
> >throughput I seem to be able to force through our IPsec is about 1.5MB/sec
> >(that's mega *bytes*, not bits). Though I'm told by several people that
> >this is not atypical for a software-only IPsec implementation, I don't
> >understand _why_.
>

> see KAME PR 229.
> http://orange.kame.net/dev/query-pr.cgi?pr=229
>
> basically, blowfish uses very big intermediate data and we cant
> hold it on the stack. we endup using static memory pool and
> hence we need spl locks. we'll try to correct it.

Thats specific to blowfish? What should we used on underpowered machines
instead?

Regards,
-is

[Jun-ichiro itojun Hagino]

>> basically, blowfish uses very big intermediate data and we cant
>> hold it on the stack. we endup using static memory pool and
>> hence we need spl locks. we'll try to correct it.
>Thats specific to blowfish?

yes.

itojun