Haren Myneni [off-list ref] writes:

quoted

On Mon, Aug 28, 2017 at 7:25 PM, Michael Ellerman [off-list ref] wrote:

quoted

Hi Haren,

Some comments inline ...

Haren Myneni [off-list ref] writes:

quoted

diff --git a/drivers/crypto/nx/nx-842-powernv.c b/drivers/crypto/nx/nx-842-powernv.c
index c0dd4c7e17d3..13089a0b9dfa 100644
--- a/drivers/crypto/nx/nx-842-powernv.c
+++ b/drivers/crypto/nx/nx-842-powernv.c

@@ -32,6 +33,9 @@ MODULE_ALIAS_CRYPTO("842-nx");

 #define WORKMEM_ALIGN        (CRB_ALIGN)
 #define CSB_WAIT_MAX (5000) /* ms */
+#define VAS_RETRIES  (10)

Where does that number come from?

Sometimes HW returns copy/paste failures. So we should retry the
request again. With 10 retries, Test running 12 hours was successful
for repeated compression/decompression requests with 1024 threads.

But why 10. Why not 5, or 100, or 1, or 10,000?

Presumably when we have to retry it means the NX is too busy to service the
request?

Do we have any way to find out how long it might be busy for?

Should we try an NX on another chip?

We should also take into account the size of our request, ie. are we
asking the NX to compress one page, or 1GB ?

If it's just one page maybe we should fall back to software immediately.

cheers