#
253624f4 |
| 04-Oct-2017 |
Pablo de Lara <pablo.de.lara.guarch@intel.com> |
app/crypto-perf: refactor common test code
Currently, there is some duplication in all the test types, in the crypto performance application.
In order to improve maintainability of this code, and e
app/crypto-perf: refactor common test code
Currently, there is some duplication in all the test types, in the crypto performance application.
In order to improve maintainability of this code, and ease future work on it, common functions have been separated in a different file that gets included in all the tests.
Signed-off-by: Pablo de Lara <pablo.de.lara.guarch@intel.com> Acked-by: Akhil Goyal <akhil.goyal@nxp.com>
show more ...
|
#
96dfeb60 |
| 12-Sep-2017 |
Anatoly Burakov <anatoly.burakov@intel.com> |
app/crypto-perf: add new PMD benchmarking mode
This patch adds a new benchmarking mode, which is intended for microbenchmarking individual parts of the cryptodev framework, specifically crypto ops a
app/crypto-perf: add new PMD benchmarking mode
This patch adds a new benchmarking mode, which is intended for microbenchmarking individual parts of the cryptodev framework, specifically crypto ops alloc-build-free, cryptodev PMD enqueue and cryptodev PMD dequeue.
It works by first benchmarking crypto operation alloc-build-free loop (no enqueues/dequeues happening), and then benchmarking enqueue and dequeue separately, by first completely filling up the TX queue, and then completely draining the RX queue.
Results are shown as cycle counts per alloc/build/free, PMD enqueue and PMD dequeue.
One new test mode is added: "pmd-cyclecount" (called with --ptest=pmd-cyclecount)
New command-line argument is also added: --pmd-cyclecount-delay-ms: this is a pmd-cyclecount-specific parameter that controls the delay between enqueue and dequeue. This is useful for benchmarking hardware acceleration, as hardware may not be able to keep up with enqueued packets. This parameter can be increased if there are large amounts of dequeue retries.
Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com> Reviewed-by: Pablo de Lara <pablo.de.lara.guarch@intel.com>
show more ...
|