On 2020-04-08 21:36, Jerin Jacob wrote:
> 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.
Initially this would be so, but buffering events might yield performance
benefits for more event devices than DSW.
In an application, it's often convenient, but sub-optimal from a
performance point of view, to do single-event enqueue operations. The
alternative is to use an application-level buffer, and the flush this
buffer with rte_event_enqueue_burst(). If you allow the event device to
buffer, you get the simplicity of single-event enqueue operations, but
without taking any noticeable performance hit.
>> + * 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.
>
DSW already does maintenance on dequeue, and works well in the above
scenario. The typical worker does not need to care about the
rte_event_maintain() functions, since it dequeues events on a regular basis.
What this RFC addresses is the more atypical (but still fairly common)
case of a port being neither dequeued to or enqueued from on a regular
basis. The timer and ethernet rx adapters are examples of such.
>> + * 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.
>> + */
