eventdev: clarify the worker thread workflow

If the RTE_EVENT_DEV_CAP_DISTRIBUTED_SCHED capability flag
is not set indicates the device is centralized and thus needs
a dedicated scheduling thread that repeatedly calls
rte_event_schedule().

Update the worker thread code snippet to match
the description.

Signed-off-by: Jerin Jacob <jerin.jacob@caviumnetworks.com>
Acked-by: Bruce Richardson <bruce.richardson@intel.com>
This commit is contained in:
Jerin Jacob 2017-05-18 16:40:41 +05:30
parent 9d646a167a
commit 0b275d32a4

View File

@ -199,20 +199,6 @@
* operation. Instead, Event drivers export Poll-Mode enqueue and dequeue
* functions to applications.
*
* An event driven based application has following typical workflow on fastpath:
* \code{.c}
* while (1) {
*
* rte_event_schedule(dev_id);
*
* rte_event_dequeue(...);
*
* (event processing)
*
* rte_event_enqueue(...);
* }
* \endcode
*
* The events are injected to event device through *enqueue* operation by
* event producers in the system. The typical event producers are ethdev
* subsystem for generating packet events, CPU(SW) for generating events based
@ -237,6 +223,15 @@
* indicates the device is centralized and thus needs a dedicated scheduling
* thread that repeatedly calls rte_event_schedule().
*
* An event driven worker thread has following typical workflow on fastpath:
* \code{.c}
* while (1) {
* rte_event_dequeue_burst(...);
* (event processing)
* rte_event_enqueue_burst(...);
* }
* \endcode
*
*/
#ifdef __cplusplus