doc/guides/eventdevs/sw.rst

   1 ..  BSD LICENSE
   2     Copyright(c) 2017 Intel Corporation. All rights reserved.
   3
   4     Redistribution and use in source and binary forms, with or without
   5     modification, are permitted provided that the following conditions
   6     are met:
   7
   8     * Redistributions of source code must retain the above copyright
   9     notice, this list of conditions and the following disclaimer.
  10     * Redistributions in binary form must reproduce the above copyright
  11     notice, this list of conditions and the following disclaimer in
  12     the documentation and/or other materials provided with the
  13     distribution.
  14     * Neither the name of Intel Corporation nor the names of its
  15     contributors may be used to endorse or promote products derived
  16     from this software without specific prior written permission.
  17
  18     THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
  19     "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
  20     LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
  21     A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
  22     OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
  23     SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
  24     LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
  25     DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
  26     THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
  27     (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
  28     OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
  29
  30 Software Eventdev Poll Mode Driver
  31 ==================================
  32
  33 The software eventdev is an implementation of the eventdev API, that provides a
  34 wide range of the eventdev features. The eventdev relies on a CPU core to
  35 perform event scheduling. This PMD can use the service core library to run the
  36 scheduling function, allowing an application to utilize the power of service
  37 cores to multiplex other work on the same core if required.
  38
  39
  40 Features
  41 --------
  42
  43 The software eventdev implements many features in the eventdev API;
  44
  45 Queues
  46  * Atomic
  47  * Ordered
  48  * Parallel
  49  * Single-Link
  50
  51 Ports
  52  * Load balanced (for Atomic, Ordered, Parallel queues)
  53  * Single Link (for single-link queues)
  54
  55 Event Priorities
  56  * Each event has a priority, which can be used to provide basic QoS
  57
  58
  59 Configuration and Options
  60 -------------------------
  61
  62 The software eventdev is a vdev device, and as such can be created from the
  63 application code, or from the EAL command line:
  64
  65 * Call ``rte_vdev_init("event_sw0")`` from the application
  66
  67 * Use ``--vdev="event_sw0"`` in the EAL options, which will call
  68   rte_vdev_init() internally
  69
  70 Example:
  71
  72 .. code-block:: console
  73
  74     ./your_eventdev_application --vdev="event_sw0"
  75
  76
  77 Scheduling Quanta
  78 ~~~~~~~~~~~~~~~~~
  79
  80 The scheduling quanta sets the number of events that the device attempts to
  81 schedule in a single schedule call performed by the service core. Note that
  82 is a *hint* only, and that fewer or more events may be scheduled in a given
  83 iteration.
  84
  85 The scheduling quanta can be set using a string argument to the vdev
  86 create call:
  87
  88 .. code-block:: console
  89
  90     --vdev="event_sw0,sched_quanta=64"
  91
  92
  93 Credit Quanta
  94 ~~~~~~~~~~~~~
  95
  96 The credit quanta is the number of credits that a port will fetch at a time from
  97 the instance's credit pool. Higher numbers will cause less overhead in the
  98 atomic credit fetch code, however it also reduces the overall number of credits
  99 in the system faster. A balanced number (eg 32) ensures that only small numbers
 100 of credits are pre-allocated at a time, while also mitigating performance impact
 101 of the atomics.
 102
 103 Experimentation with higher values may provide minor performance improvements,
 104 at the cost of the whole system having less credits. On the other hand,
 105 reducing the quanta may cause measurable performance impact but provide the
 106 system with a higher number of credits at all times.
 107
 108 A value of 32 seems a good balance however your specific application may
 109 benefit from a higher or reduced quanta size, experimentation is required to
 110 verify possible gains.
 111
 112 .. code-block:: console
 113
 114     --vdev="event_sw0,credit_quanta=64"
 115
 116
 117 Limitations
 118 -----------
 119
 120 The software eventdev implementation has a few limitations. The reason for
 121 these limitations is usually that the performance impact of supporting the
 122 feature would be significant.
 123
 124
 125 "All Types" Queues
 126 ~~~~~~~~~~~~~~~~~~
 127
 128 The software eventdev does not support creating queues that handle all types of
 129 traffic. An eventdev with this capability allows enqueueing Atomic, Ordered and
 130 Parallel traffic to the same queue, but scheduling each of them appropriately.
 131
 132 The reason to not allow Atomic, Ordered and Parallel event types in the
 133 same queue is that it causes excessive branching in the code to enqueue packets
 134 to the queue, causing a significant performance impact.
 135
 136 The ``RTE_EVENT_DEV_CAP_QUEUE_ALL_TYPES`` flag is not set in the
 137 ``event_dev_cap`` field of the ``rte_event_dev_info`` struct for the software
 138 eventdev.
 139
 140 Distributed Scheduler
 141 ~~~~~~~~~~~~~~~~~~~~~
 142
 143 The software eventdev is a centralized scheduler, requiring a service core to
 144 perform the required event distribution. This is not really a limitation but
 145 rather a design decision.
 146
 147 The ``RTE_EVENT_DEV_CAP_DISTRIBUTED_SCHED`` flag is not set in the
 148 ``event_dev_cap`` field of the ``rte_event_dev_info`` struct for the software
 149 eventdev.
 150
 151 Dequeue Timeout
 152 ~~~~~~~~~~~~~~~
 153
 154 The eventdev API supports a timeout when dequeuing packets using the
 155 ``rte_event_dequeue_burst`` function.
 156 This allows a core to wait for an event to arrive, or until ``timeout`` number
 157 of ticks have passed. Timeout ticks is not supported by the software eventdev
 158 for performance reasons.