On 10 August 2017 at 22:33, Farley, Peter x23353 < [email protected]> wrote:
> OT: I would disagree that ICSF is the "overall better choice". IMHO, if > you do not need unique Crypto Express co-processor functions or completely > and totally secure keys then ICSF is just wasted overhead compared to using > the native CPACF instructions. > > I have measured the difference between using native CPACF and the ICSF > equivalents for "clear key" computations and it is many, many orders of > magnitude slower to use ICSF. That is unacceptable. > With an asynchronous interface to CPEX you would need to poll and introduce some latency unless you wish to spin while CPEX is processing. For operations where the CPEX is much better, spinning can be justified with a single threaded workload. Obviously when you need to have the CPEX do the symmetric encryption because you don't have the keys yourself, then it's another matter. Overhead can be an issue. When measuring the Linux on Z crypto, I found that the flexible crypto engine layer introduced so much overhead that it was cheaper to do some easier symmetric encryption (on short blocks) in software than involve the engine that uses CPACF to do it. This changed when the openssl project got a developer with interest in S/390 architecture and put the native CPACF instructions in the mainline code. Rob
