On Tue, 8 Nov 2005, J.C. Roberts wrote:
> On Tue, 08 Nov 2005 08:51:06 +0100, Vincent Bernat <[EMAIL PROTECTED]>
> wrote:
>
> >Hi !
> >
> >I have several questions about IPsec performance in OpenBSD. I am
> >using IPsec to maintain more than 60 tunnels and it performs well when
> >those tunnels are idle. Tunnels are either using 3DES or AES. 3DES is
> >due to the fact that clients are using Windows where AES is not
> >available.
> >
> >OpenBSD is running on a Celeron 2.4 GHz and openssl speed aes gives 70
> >MB/s and des-ede3 gives 15 MB/s. With 40 Mb/s (megabits/s) of traffic,
> >the processor is used at 100%. Why such a difference with the results
> >of openssl speed.
Well, from your data I would expect the troughhput to be somewhere
between 15 and 70MB/s. Yo do not specify how much traffic is using aes
vs 3des.
> Celeron? If your goal is to melt an nearly worthless processor into a
> completely worthless chunk of slag, Celeron is perfect.
>
> >I have added an Hifn 7955 crypto card. However, after one hour of
> >managing the 60 tunnels, it becomes impossible to do any symmetric
> >crypto. There is nothing in the dmesg about that. The only solution is
> >to reboot. With the card disabled, there is no such problem. Any idea
> >of why I have this problem ?
Apart from issues in the hifn driver, having a crypto accelarator only
helps if your processor is relatively slow. With fast main processors,
the overhead of communicating with the crypto coprocessor becomes too
big. Of course it depends on the kind of coprocessor and the kind of
crypto work done. Symmetric encryption has different computing needs
that asymetric stuff.
> Just a wild guess but it possibly has something to do with the fact HiFn
> refuses to make their documentation publicly available and because of
> this support in OpenBSD is limited. As someone who went to lunch with
> the HiFn CEO and VP of engineering over a year ago to address this
> problem, the most I can say is I was told a lot of things but nothing
> was actually done... The worst part about the experience was the fact
> Theo told be it would be all talk and no action before I ever met with
> HiFn.
>
> Few things are worse than getting an implied "I told you so" from Theo.
> All the same, at least I tried.
>
> >What kind of hardware will perform 3DES and AES encryption well ? A C3
> >processor has AES encryption built-in but I must keep 3DES encryption
> >as well and those processors are very slow on general
> >operations. Would an Opteron 2.2 Ghz performs better than an Intel
> >EM64T Xeon 3 GHz ?
> >
> >If I choose a multiprocessor system, will OpenBSD be able to use
> >efficienly the two processors for doing IPsec stuff ?
> >
>
> Now think to yourself on this one. You've got 60 tunnels that must be
> serviced by the processor. A single threaded processor with limited
> cache and task switching (i.e. Celeron) is the wrong choice if not the
> worst choice you could make. The fake multi-core Intel stuff called
> "Hyper Threading" is a small step in the right direction. Next up would
> be real multi-core processors, and lastly, your best choice is having
> multiple multi-core processors.
AFAIK, this is wrong. IPSEC is done by the kernel, and kernel code
does not benefit from MP.
>
> Having an custom ASIC (processor) specifically designed to do crypto
> running as a co-processing slave to your system CPU is a great and
> wonderful thing, but only if it actually works. Though it might not
> solve your immediate problem, it would be good for the project if you
> contacted HiFn yourself and asked them why their documentation is not
> publicly available so the open source world can develop drivers.
>
> "Chris Kenber" ckenber(at)hifn.com CEO
> "Russell Dietz" RDietz(at)hifn.com VP Eng
>
> If, and only if, your real limitation is actually the processing power
> needed for crypto, then obviously having more processing power will most
> likely solve the problem. Before you decide the real problem is
> processing power, please do yourself a favor and look for other possible
> bottlenecks, like interrupt, network, memory... A machine with multiple
> general purpose multi-core processor is not cheap (i.e. dual or quad
> multi-core Opterons would be sweet). Tossing a general purpose CPU at a
> specific processing problem will help but it's better and cheaper to use
> custom co-processors, like crypto ASIC's, to address the specific
> processing task.
I would love to see some actual numbers of people running various
hardware. Otherwise this is all just speculation, partly based on
wrong assupmtions.
-Otto
