doc: fix crypto scheduler command line examples

[dpdk.git] / doc / guides / cryptodevs / scheduler.rst

diff --git a/doc/guides/cryptodevs/scheduler.rst b/doc/guides/cryptodevs/scheduler.rst
index af54daf..f3ee88a 100644 (file)
--- a/doc/guides/cryptodevs/scheduler.rst
+++ b/doc/guides/cryptodevs/scheduler.rst
@@ -72,10 +72,10 @@ Initialization
 
 To use the PMD in an application, user must:
 
-* Call rte_eal_vdev_init("crpyto_scheduler") within the application.
+* Call rte_vdev_init("crypto_scheduler") within the application.
 
-* Use --vdev="crpyto_scheduler" in the EAL options, which will call
-  rte_eal_vdev_init() internally.
+* Use --vdev="crypto_scheduler" in the EAL options, which will call
+  rte_vdev_init() internally.
 
 
 The following parameters (all optional) can be provided in the previous
@@ -94,11 +94,19 @@ two calls:
   here. Multiple cryptodevs can be attached initially by presenting this
   parameter multiple times.
 
+* mode: Specify the scheduling mode of the PMD. The supported scheduling
+  mode parameter values are specified in the "Cryptodev Scheduler Modes
+  Overview" section.
+
+* ordering: Specify the status of the crypto operations ordering feature.
+  The value of this parameter can be "enable" or "disable". This feature
+  is disabled by default.
+
 Example:
 
 .. code-block:: console
 
-    ... --vdev "crypto_aesni_mb_pmd,name=aesni_mb_1" --vdev "crypto_aesni_mb_pmd,name=aesni_mb_2" --vdev "crypto_scheduler_pmd,slave=aesni_mb_1,slave=aesni_mb_2" ...
+    ... --vdev "crypto_aesni_mb0,name=aesni_mb_1" --vdev "crypto_aesni_mb1,name=aesni_mb_2" --vdev "crypto_scheduler,slave=aesni_mb_1,slave=aesni_mb_2" ...
 
 .. note::
 
@@ -122,6 +130,8 @@ operation:
 
 *   **CDEV_SCHED_MODE_ROUNDROBIN:**
 
+   *Initialization mode parameter*: **round-robin**
+
    Round-robin mode, which distributes the enqueued burst of crypto ops
    among its slaves in a round-robin manner. This mode may help to fill
    the throughput gap between the physical core and the existing cryptodevs
@@ -129,6 +139,8 @@ operation:
 
 *   **CDEV_SCHED_MODE_PKT_SIZE_DISTR:**
 
+   *Initialization mode parameter*: **packet-size-distr**
+
    Packet-size based distribution mode, which works with 2 slaves, the primary
    slave and the secondary slave, and distributes the enqueued crypto
    operations to them based on their data lengths. A crypto operation will be
@@ -141,3 +153,45 @@ operation:
    process additional crypto workload than what the QAT cryptodev can handle on
    its own, by making use of the available CPU cycles to deal with smaller
    crypto workloads.
+
+   The threshold is set to 128 bytes by default. It can be updated by calling
+   function **rte_cryptodev_scheduler_option_set**. The parameter of
+   **option_type** must be **CDEV_SCHED_OPTION_THRESHOLD** and **option** should
+   point to a rte_cryptodev_scheduler_threshold_option structure filled with
+   appropriate threshold value. Please NOTE this threshold has be a power-of-2
+   unsigned integer.
+
+*   **CDEV_SCHED_MODE_FAILOVER:**
+
+   *Initialization mode parameter*: **fail-over**
+
+   Fail-over mode, which works with 2 slaves, the primary slave and the
+   secondary slave. In this mode, the scheduler will enqueue the incoming
+   crypto operation burst to the primary slave. When one or more crypto
+   operations fail to be enqueued, then they will be enqueued to the secondary
+   slave.
+
+*   **CDEV_SCHED_MODE_MULTICORE:**
+
+   *Initialization mode parameter*: **multi-core**
+
+   Multi-core mode, which distributes the workload with several (up to eight)
+   worker cores. The enqueued bursts are distributed among the worker cores in a
+   round-robin manner. If scheduler cannot enqueue entire burst to the same worker,
+   it will enqueue the remaining operations to the next available worker.
+   For pure small packet size (64 bytes) traffic however the multi-core mode is not
+   an optimal solution, as it doesn't give significant per-core performance improvement.
+   For mixed traffic (IMIX) the optimal number of worker cores is around 2-3.
+   For large packets (1.5 Kbytes) scheduler shows linear scaling in performance
+   up to eight cores.
+   Each worker uses its own slave cryptodev. Only software cryptodevs
+   are supported. Only the same type of cryptodevs should be used concurrently.
+
+   The multi-core mode uses one extra parameter:
+
+   * corelist: Semicolon-separated list of logical cores to be used as workers.
+     The number of worker cores should be equal to the number of slave cryptodevs.
+
+   Example:
+    ... --vdev "crypto_aesni_mb1,name=aesni_mb_1" --vdev "crypto_aesni_mb_pmd2,name=aesni_mb_2" \
+    --vdev "crypto_scheduler,slave=aesni_mb_1,slave=aesni_mb_2,mode=multi-core,corelist=23;24" ...