+
+* **CDEV_SCHED_MODE_PKT_SIZE_DISTR:**
+
+ *Initialization mode parameter*: **packet-size-distr**
+
+ Packet-size based distribution mode, which works with 2 workers, the primary
+ worker and the secondary worker, and distributes the enqueued crypto
+ operations to them based on their data lengths. A crypto operation will be
+ distributed to the primary worker if its data length is equal to or bigger
+ than the designated threshold, otherwise it will be handled by the secondary
+ worker.
+
+ A typical usecase in this mode is with the QAT cryptodev as the primary and
+ a software cryptodev as the secondary worker. This may help applications to
+ 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. It is possible to use **mode_param** initialization
+ parameter to achieve the same purpose. For example:
+
+ ... --vdev "crypto_scheduler,mode=packet-size-distr,mode_param=threshold:512" ...
+
+ The above parameter will overwrite the threshold value to 512.
+
+* **CDEV_SCHED_MODE_FAILOVER:**
+
+ *Initialization mode parameter*: **fail-over**
+
+ Fail-over mode, which works with 2 workers, the primary worker and the
+ secondary worker. In this mode, the scheduler will enqueue the incoming
+ crypto operation burst to the primary worker. When one or more crypto
+ operations fail to be enqueued, then they will be enqueued to the secondary
+ worker.
+
+* **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 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 worker 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,worker=aesni_mb_1,worker=aesni_mb_2,mode=multi-core,corelist=23;24" ...