The decision of coprocessor vs accelerator is performance/capacity based. When configured as an accelerator you can process significantly more transactions per second than you can as a coprocessor. The differences depend on which cards (CEX2, CEX3 or CEX4S) as well as which machines you are using and which version of z/OS and ICSF that you are running. There are some performance white papers available at http://www.ibm.com/systems/z/advantages/security/zec12cryptography.html (for the zEC12) and http://www.ibm.com/systems/z/advantages/security/z10cryptography.html (for the z10 and z196). Each document has a section on SSL performance.
But you also must consider what functions you need available. When all available crypto cards are configured as accelerators, then they can only handle the SSL Handshake APIs. If you need to perform some other operations (secure key DES/TDES, PIN functions, key management operations) then you must have at least one coprocessor configured. The EP11 configuration option is different. If you configure in EP11 mode, then the card only supports PKCS #11 operations. So, my general recommendation would be: 1) Configure in EP11 mode only when you need to support PKCS #11 secure key operations (and you have a zEC12 with CEX4S cards). And configure as many engines as you need to support your PKCS #11 workload. (Again, see the performance white papers mentioned above for some ballpark numbers, but you'll probably need to protype your app to determine how many engines you'll need.) 2) Ignoring EP11 mode, start with your CEX2, CEX3 and CEX4S configured as a coprocessor, because that environment can support all operations. 3) If those coprocessors don't provide the SSL performance or throughput that you require, then consider reconfiguring one or more as accelerators. From the zEC12 white paper above, a CEX4C can drive about 2250 handshakes per second, while an accelerator can drive almost 4400 per second. If you have 4 CEXSs available (assigned to the LPAR) and you need to drive 10,000 handshakes per second, then configuring all four engines as coprocessors won't cut it. They would only drive about 9000 (4x2250) handshakes per second. Reconfiguring one of the CEX4S as an accelerator would meet your requirements (3X2250 + 4400), but not provide much room for growth of the SSL workload. And if you have any secure key work, then you must ensure that you have at least one coprocessor available. And you must consider the volume of those secure key operations. From the same report, a CEX4S configured as a coprocessor can support just over 1800 key generations (operational DES KEY GENKY key) per second. IF you need 2000 key generations per second, then you'll need at least two coprocessors to handle that load. Unfortunately, the crypto metrics that are provided can lead to some confusion. When you run the RMF Crypto Hardware Activity report, it reports on the total usage of the crypto cards. Each crypto engine can be shared by up to 16 LPARs so the report reflects the total utilization across all of those LPARs. There is no way to tell that LPAR 1 is doing only secure key DES/TDES and AES encryption, while LPAR 2 is only doing SSL handshakes and LPAR 3 is only doing PIN functions. That means you must have some understanding of the work running on your systems. So, I also recommend that as you are rolling out new applications that leverage the cards, you should try to do some prototyping and capture metrics for the specific app in terms of it's crypto utilization. Capture the metrics and then as you roll it into production try to develop trend lines on the crypto utilization. With the CEX4S, there is only a single engine per feature, so there is more granularity in terms of adding more engines. The CEX2 and CEX3 on the Enterprise Class machines had two crypto engines per feature, so you had to add two engines at a time. With the CEX4S you can increment one engine at a time. Hope this helps. Greg IBM ATS, Washington Systems Center Supporting crypto on System z Not sure why, but I'm not seeing a button to imbed the original post in my append ... so I've copied and pasted part of it below: Would the main reason for configuring these cards as an accelerator or EP11 mode be for maximum performance, or to ensure that only a subset of the available ICSF API's can be used on that card? Mark Jacobs .... ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
