>-----Original Message----- >From: Trahe, Fiona >Sent: Tuesday, February 7, 2017 5:33 PM >To: [email protected] >Cc: De Lara Guarch, Pablo <[email protected]>; Mrozowicz, >SlawomirX <[email protected]>; Jain, Deepak K ><[email protected]>; Trahe, Fiona <[email protected]>; Griffin, >John <[email protected]>; Doherty, Declan <[email protected]> >Subject: [PATCH] doc: add limitations section to cryptoperf guide > >Add limitations to use of the dpdk-test-crypto-perf tool for hardware >accelerator measurements > >Signed-off-by: Fiona Trahe <[email protected]> >--- > doc/guides/tools/cryptoperf.rst | 16 ++++++++++++++++ > 1 files changed, 16 insertions(+), 0 deletions(-) > >diff --git a/doc/guides/tools/cryptoperf.rst b/doc/guides/tools/cryptoperf.rst >index 6832312..af58e78 100644 >--- a/doc/guides/tools/cryptoperf.rst >+++ b/doc/guides/tools/cryptoperf.rst >@@ -41,6 +41,22 @@ chain mode have to be specified in the command line as >application parameters. These parameters are checked using device >capabilities structure. > >+Limitations: >+------------ >+On hardware devices the cycle-count doesn't always represent the actual >+offload cost. The cycle-count only represents the offload cost when the >+hardware accelerator is not fully loaded, when loaded the cpu cycles >+freed up by the offload are still consumed by the test tool and included in >the cycle-count. >+These cycles are consumed by retries and inefficient API calls >+enqueuing and dequeuing smaller bursts than specified by the cmdline >+parameter. This results in a larger cycle-count measurement and should >+not be interpreted as an offload cost measurement. >+ >+On hardware devices the throughput measurement is not necessarily the >+maximum possible for the device, e.g. it may be necessary to use >+multiple cores to keep the hardware accelerator fully loaded and so measure >maximum throughput. >+ >+ > Compiling the Application > ------------------------- > >-- >1.7.0.7
>From my point of view this information is ok. Sławomir
