Richard, I tried responding to your note from three different email addresses. I keep getting a response back, apparently from your server, that delivery is delayed. Not sure what's going on.
I absolutely agree with Todd's comments: It's hard to evaluate performance metrics or do capacity planing on the cards because it is highly dependent on your workload AND the crypto infrastructure doesn't provide a lot of details about the work it is doing. With HCR77C1 there are some new stats that are available though that might help. My general recommendation is to leave your cards as coprocessors (the default) until either: a) you need PKCS11 secure key support or b) the RMF Crypto Hardware Activity Report shows that the cards are getting busy AND you know that your crypto workload is supported on an ccelerator In the first case, if you need PKCS11 secure key, then your only option is to change the cards to EP11 mode. (Don't forget for EP11 mode, you must have a TKE to load the master keys into that card.) In the second case, if your cards are getting busy AND you know that your workload includes SSL (aka TLS) operations, then switching a card to an accelerator may help. When configured as an accelerator the card can only perform public key operations. A coprocessor can perform those same public key operations, just not as many of them. In terms of 'busy', you need to know what your normal is. To take Todd's comments a bit further, if your cards are running at 75%, doubling the TDES workload may not max the card out. But doubling the RSA workload might. It depends on how much of that 75% is RSA vs TDES vs ECC vs PIN operations vs Key Generation. So you need to monitor the RMF Crypto Hardware Activity Report and know what your growth rate is and at least have an idea of what kind of work you are sending to the cards. If it's the right type of work (public key ops), then it might make sense to reconfigure a card as an accelerator. Don't forget to consider redundancy. A coprocessor will still do public key operations if the accelerator fails. But the accelerator can't back up the additional functionality on a coprocessor. Finally, be aware that the potential benefit of converting a CEX6S card to an accelerator is much smaller than converting a CEX5S (or earlier card) to an accelerator. On the older cards, an accelerator could drive approximately twice as many SSL operations as a coprocessor. A CEX6S accelerator can only drive about 15% more SSL operations than a CEX6S coprocessor. Greg Greg Boyd www.mainframecrypto.com On Thu, 4 Oct 2018 14:11:55 +0000, Richards, Robert B. <[email protected]> wrote: >I sent an email to Greg Boyd (Greg Boyd >[email protected]<mailto:[email protected]>) asking for >a response to a coworker's question below. In case Greg is otherwise engaged, >I am casting a wider net to get an answer in a timely fashion (i.e. ASAP :)). > >Any takers? > >Thanks in advance, > >Bob > >The question: > >We currently have a total of 3 Crypto Express4 Accelerators and 3 Crypto >Express4 CCA coprocessors configured and shared with all of our 8 z/OS LPARS >and 1 Crypto Express4 CCA coprocessor defined to z/VM for Linux. We need to >understand what utilization should be allowed for each of these to help us >determine if we have too many or when we should be getting additional. > > >CRYPTO SERIAL >FEATURE NUMBER STATUS AES DES ECC RSA P11 >------- -------- -------------------- --- --- --- --- --- > 4C00 00000000 Active A A I A > 4A01 N/A Active > 4C02 00000000 Active A A I A > 4A03 N/A Active > 4C04 00000000 Active A A I A > 4A05 N/A Active > > > >---------------------------------------------------------------------- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
