X-Git-Url: http://git.droids-corp.org/?a=blobdiff_plain;f=doc%2Fguides%2Fcryptodevs%2Fscheduler.rst;h=e7e0247b660b1b84741346534de9e9444401edcc;hb=37553e5f25e872f6d01693f979ae927e4371a04b;hp=04823316184e06fca50982f41a384b4905badd4e;hpb=a0e805ee086a87b2a787a4deb139775a01790c7c;p=dpdk.git

diff --git a/doc/guides/cryptodevs/scheduler.rst b/doc/guides/cryptodevs/scheduler.rst
index 0482331618..e7e0247b66 100644
--- 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
@@ -106,7 +106,7 @@ 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::
 
@@ -154,6 +154,13 @@ operation:
    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**
@@ -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.
+
+*   **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" ...