doc/guides/cryptodevs/scheduler.rst

   1 ..  BSD LICENSE
   2     Copyright(c) 2017 Intel Corporation. All rights reserved.
   3     All rights reserved.
   4
   5     Redistribution and use in source and binary forms, with or without
   6     modification, are permitted provided that the following conditions
   7     are met:
   8
   9     * Redistributions of source code must retain the above copyright
  10     notice, this list of conditions and the following disclaimer.
  11     * Redistributions in binary form must reproduce the above copyright
  12     notice, this list of conditions and the following disclaimer in
  13     the documentation and/or other materials provided with the
  14     distribution.
  15     * Neither the name of Intel Corporation nor the names of its
  16     contributors may be used to endorse or promote products derived
  17     from this software without specific prior written permission.
  18
  19     THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
  20     "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
  21     LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
  22     A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
  23     OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
  24     SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
  25     LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
  26     DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
  27     THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
  28     (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
  29     OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
  30
  31 Cryptodev Scheduler Poll Mode Driver Library
  32 ============================================
  33
  34 Scheduler PMD is a software crypto PMD, which has the capabilities of
  35 attaching hardware and/or software cryptodevs, and distributes ingress
  36 crypto ops among them in a certain manner.
  37
  38 .. figure:: img/scheduler-overview.*
  39
  40    Cryptodev Scheduler Overview
  41
  42
  43 The Cryptodev Scheduler PMD library (**librte_pmd_crypto_scheduler**) acts as
  44 a software crypto PMD and shares the same API provided by librte_cryptodev.
  45 The PMD supports attaching multiple crypto PMDs, software or hardware, as
  46 slaves, and distributes the crypto workload to them with certain behavior.
  47 The behaviors are categorizes as different "modes". Basically, a scheduling
  48 mode defines certain actions for scheduling crypto ops to its slaves.
  49
  50 The librte_pmd_crypto_scheduler library exports a C API which provides an API
  51 for attaching/detaching slaves, set/get scheduling modes, and enable/disable
  52 crypto ops reordering.
  53
  54 Limitations
  55 -----------
  56
  57 * Sessionless crypto operation is not supported
  58 * OOP crypto operation is not supported when the crypto op reordering feature
  59   is enabled.
  60
  61
  62 Installation
  63 ------------
  64
  65 To build DPDK with CRYTPO_SCHEDULER_PMD the user is required to set
  66 CONFIG_RTE_LIBRTE_PMD_CRYPTO_SCHEDULER=y in config/common_base, and
  67 recompile DPDK
  68
  69
  70 Initialization
  71 --------------
  72
  73 To use the PMD in an application, user must:
  74
  75 * Call rte_vdev_init("crypto_scheduler") within the application.
  76
  77 * Use --vdev="crypto_scheduler" in the EAL options, which will call
  78   rte_vdev_init() internally.
  79
  80
  81 The following parameters (all optional) can be provided in the previous
  82 two calls:
  83
  84 * socket_id: Specify the socket where the memory for the device is going
  85   to be allocated (by default, socket_id will be the socket where the core
  86   that is creating the PMD is running on).
  87
  88 * max_nb_sessions: Specify the maximum number of sessions that can be
  89   created. This value may be overwritten internally if there are too
  90   many devices are attached.
  91
  92 * slave: If a cryptodev has been initialized with specific name, it can be
  93   attached to the scheduler using this parameter, simply filling the name
  94   here. Multiple cryptodevs can be attached initially by presenting this
  95   parameter multiple times.
  96
  97 * mode: Specify the scheduling mode of the PMD. The supported scheduling
  98   mode parameter values are specified in the "Cryptodev Scheduler Modes
  99   Overview" section.
 100
 101 * ordering: Specify the status of the crypto operations ordering feature.
 102   The value of this parameter can be "enable" or "disable". This feature
 103   is disabled by default.
 104
 105 Example:
 106
 107 .. code-block:: console
 108
 109     ... --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" ...
 110
 111 .. note::
 112
 113     * The scheduler cryptodev cannot be started unless the scheduling mode
 114       is set and at least one slave is attached. Also, to configure the
 115       scheduler in the run-time, like attach/detach slave(s), change
 116       scheduling mode, or enable/disable crypto op ordering, one should stop
 117       the scheduler first, otherwise an error will be returned.
 118
 119     * The crypto op reordering feature requires using the userdata field of
 120       every mbuf to be processed to store temporary data. By the end of
 121       processing, the field is set to pointing to NULL, any previously
 122       stored value of this field will be lost.
 123
 124
 125 Cryptodev Scheduler Modes Overview
 126 ----------------------------------
 127
 128 Currently the Crypto Scheduler PMD library supports following modes of
 129 operation:
 130
 131 *   **CDEV_SCHED_MODE_ROUNDROBIN:**
 132
 133    *Initialization mode parameter*: **round-robin**
 134
 135    Round-robin mode, which distributes the enqueued burst of crypto ops
 136    among its slaves in a round-robin manner. This mode may help to fill
 137    the throughput gap between the physical core and the existing cryptodevs
 138    to increase the overall performance.
 139
 140 *   **CDEV_SCHED_MODE_PKT_SIZE_DISTR:**
 141
 142    *Initialization mode parameter*: **packet-size-distr**
 143
 144    Packet-size based distribution mode, which works with 2 slaves, the primary
 145    slave and the secondary slave, and distributes the enqueued crypto
 146    operations to them based on their data lengths. A crypto operation will be
 147    distributed to the primary slave if its data length is equal to or bigger
 148    than the designated threshold, otherwise it will be handled by the secondary
 149    slave.
 150
 151    A typical usecase in this mode is with the QAT cryptodev as the primary and
 152    a software cryptodev as the secondary slave. This may help applications to
 153    process additional crypto workload than what the QAT cryptodev can handle on
 154    its own, by making use of the available CPU cycles to deal with smaller
 155    crypto workloads.
 156
 157    The threshold is set to 128 bytes by default. It can be updated by calling
 158    function **rte_cryptodev_scheduler_option_set**. The parameter of
 159    **option_type** must be **CDEV_SCHED_OPTION_THRESHOLD** and **option** should
 160    point to a rte_cryptodev_scheduler_threshold_option structure filled with
 161    appropriate threshold value. Please NOTE this threshold has be a power-of-2
 162    unsigned integer.
 163
 164 *   **CDEV_SCHED_MODE_FAILOVER:**
 165
 166    *Initialization mode parameter*: **fail-over**
 167
 168    Fail-over mode, which works with 2 slaves, the primary slave and the
 169    secondary slave. In this mode, the scheduler will enqueue the incoming
 170    crypto operation burst to the primary slave. When one or more crypto
 171    operations fail to be enqueued, then they will be enqueued to the secondary
 172    slave.
 173
 174 *   **CDEV_SCHED_MODE_MULTICORE:**
 175
 176    *Initialization mode parameter*: **multi-core**
 177
 178    Multi-core mode, which distributes the workload with several (up to eight)
 179    worker cores. The enqueued bursts are distributed among the worker cores in a
 180    round-robin manner. If scheduler cannot enqueue entire burst to the same worker,
 181    it will enqueue the remaining operations to the next available worker.
 182    For pure small packet size (64 bytes) traffic however the multi-core mode is not
 183    an optimal solution, as it doesn't give significant per-core performance improvement.
 184    For mixed traffic (IMIX) the optimal number of worker cores is around 2-3.
 185    For large packets (1.5 Kbytes) scheduler shows linear scaling in performance
 186    up to eight cores.
 187    Each worker uses its own slave cryptodev. Only software cryptodevs
 188    are supported. Only the same type of cryptodevs should be used concurrently.
 189
 190    The multi-core mode uses one extra parameter:
 191
 192    * corelist: Semicolon-separated list of logical cores to be used as workers.
 193      The number of worker cores should be equal to the number of slave cryptodevs.
 194      These cores should be present in EAL core list parameter and
 195      should not be used by the application or any other process.
 196
 197    Example:
 198     ... --vdev "crypto_aesni_mb1,name=aesni_mb_1" --vdev "crypto_aesni_mb_pmd2,name=aesni_mb_2" \
 199     --vdev "crypto_scheduler,slave=aesni_mb_1,slave=aesni_mb_2,mode=multi-core,corelist=23;24" ...