Hi folks,

As mentioned in a previous thread*, the eventdev documentation is unclear on 
what the user can expect when a device is stopped, possibly re-configured, and 
restarted. The documentation states that:

* If the application wants to change the configuration (i.e. call
* rte_event_dev_configure(), rte_event_queue_setup(), or
* rte_event_port_setup()), it must call rte_event_dev_stop() first to stop the
* device and then do the reconfiguration before calling rte_event_dev_start()
* again. The schedule, enqueue and dequeue functions should not be invoked
* when the device is stopped.

And:

/**
* Stop an event device. The device can be restarted with a call to
* rte_event_dev_start()
*
* @param dev_id
*   Event device identifier.
*/
void
rte_event_dev_stop(uint8_t dev_id);

Specifically, the documentation is unclear on whether events that are queued in 
the device when rte_event_dev_stop() is called will remain there after 
rte_event_dev_start()? And does this depend on whether 
rte_event_dev_configure() or rte_event_queue_setup() are called? (There are 
probably other aspects that need clarification, but this is a starting point.)

Hopefully we can agree on a common behavior, or else perhaps capabilities flags 
are in order. I propose we take the (in my view) simplest approach, that 
eventdevs will not preserve events when a device is stopped and restarted. 
(Thus to avoid memory leaks, the application is responsible for flushing events 
out of the device before stopping it.) This is simple to support in the sw PMD, 
and I would expect this to be simpler for hardware devices as well.

Thoughts?

Thanks,
Gage

*http://dpdk.org/ml/archives/dev/2018-January/085777.html

Reply via email to