On Wed, Apr 8, 2020 at 11:27 PM Mattias Rönnblom <mattias.ronnb...@ericsson.com> wrote: > > Extend Eventdev API to allow for event devices which require various > forms of internal processing to happen, even when events are not > enqueued to or dequeued from a port. > > Signed-off-by: Mattias Rönnblom <mattias.ronnb...@ericsson.com> > --- > lib/librte_eventdev/rte_eventdev.h | 65 ++++++++++++++++++++++++++ > lib/librte_eventdev/rte_eventdev_pmd.h | 14 ++++++ > 2 files changed, 79 insertions(+) > > diff --git a/lib/librte_eventdev/rte_eventdev.h > b/lib/librte_eventdev/rte_eventdev.h > index 226f352ad..d69150792 100644 > --- a/lib/librte_eventdev/rte_eventdev.h > +++ b/lib/librte_eventdev/rte_eventdev.h > @@ -289,6 +289,15 @@ struct rte_event; > * single queue to each port or map a single queue to many port. > */ > > +#define RTE_EVENT_DEV_CAP_REQUIRES_MAINT (1ULL << 9) > +/**< Event device requires calls to rte_event_maintain() during
This scheme would call for DSW specific API handling in fastpath. > + * periods when neither rte_event_dequeue_burst() nor The typical worker thread will be while (1) { rte_event_dequeue_burst(); ..proess.. rte_event_enqueue_burst(); } If so, Why DSW driver can't do the maintenance in driver context in dequeue() call. > + * rte_event_enqueue_burst() are called on a port. This will allow the > + * event device to perform internal processing, such as flushing > + * buffered events, return credits to a global pool, or process > + * signaling related to load balancing. > + */