doc: fix format in OpenSSL installation guide
[dpdk.git] / doc / guides / cryptodevs / scheduler.rst
index 0482331..e7e0247 100644 (file)
@@ -72,10 +72,10 @@ Initialization
 
 To use the PMD in an application, user must:
 
 
 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
 
 
 The following parameters (all optional) can be provided in the previous
@@ -106,7 +106,7 @@ Example:
 
 .. code-block:: console
 
 
 .. 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::
 
 
 .. note::
 
@@ -154,6 +154,13 @@ operation:
    its own, by making use of the available CPU cycles to deal with smaller
    crypto workloads.
 
    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**
 *   **CDEV_SCHED_MODE_FAILOVER:**
 
    *Initialization mode parameter*: **fail-over**
@@ -163,3 +170,30 @@ operation:
    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.
    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.
+     These cores should be present in EAL core list parameter and
+     should not be used by the application or any other process.
+
+   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" ...