Re: [IPsec] Discussion of draft-pwouters-ipsecme-multi-sa-performance

[Tero Kivinen <[e-mail]>]

Valery Smyslov writes:
> > There is no point of one having for example 10 fast cpus sending
> > traffic over 10 Child SA, when the receiving end only has two cpus
> > which are about same than the other ends cpus. The receiving end will
> > not be able to keep up with the traffic it is getting in, thus it will
> > drop packets as it can't decrypt them fast enough.
> 
> I'm not so sure. Consider the situation when one host a single HSMs
> which is optimized for high-performance crypto operations,
> while the other is a general purpose server with several tens of CPUs.
> In this situation the HSM beats any CPU in performance, so if the 
> HSM can handle several SAs, it's beneficial to create as many SAs as 
> it can handle and distribute those SAs over CPUs on the other peer.

Whether HSM is faster than CPU depends on so many matters, and I have
seen so many cases where when new CPU architecture came out, then it
was again faster to do crypto on the CPU than offload it to HSM as the
interaction between the CPU and HSM was too slow. And then HSM was
upgraded and it was again faster etc.

I think they were always within order of magnitude of each other,
i.e., HSM was maximally only 10 times faster than CPU. There usually
was no need to do them faster than that as the line speeds used
limited the speeds needed anyways.

But my experience of them is more than 10 years old, so this might
have changed lately.

Question is how many CPUs do you need to saturate 100 Gbit/s network
link compared to how many HSM CPUs you need? is there more than 10
times bigger number between them.

Do you have any real world values for those? I.e., how fast can one
modern cpu do crypto (just plain crypto, no ipsec etc), and how fast
can some modern crypto hardware do the same?
-- 
[e-mail]