Re: [PATCH v3 1/3] lib: introduce dispatcher library

[Jerin Jacob <jerinjacobk@gmail.com>]

On Mon, Sep 4, 2023 at 6:39 PM Mattias Rönnblom
<mattias.ronnblom@ericsson.com> wrote:
>
> The purpose of the dispatcher library is to help reduce coupling in an
> Eventdev-based DPDK application.
>
> In addition, the dispatcher also provides a convenient and flexible
> way for the application to use service cores for application-level
> processing.
>
> Signed-off-by: Mattias Rönnblom <mattias.ronnblom@ericsson.com>
> Tested-by: Peter Nilsson <peter.j.nilsson@ericsson.com>
> Reviewed-by: Heng Wang <heng.wang@ericsson.com>
>

> +static inline void
> +evd_dispatch_events(struct rte_dispatcher *dispatcher,
> +                   struct rte_dispatcher_lcore *lcore,
> +                   struct rte_dispatcher_lcore_port *port,
> +                   struct rte_event *events, uint16_t num_events)
> +{
> +       int i;
> +       struct rte_event bursts[EVD_MAX_HANDLERS][num_events];
> +       uint16_t burst_lens[EVD_MAX_HANDLERS] = { 0 };
> +       uint16_t drop_count = 0;
> +       uint16_t dispatch_count;
> +       uint16_t dispatched = 0;
> +
> +       for (i = 0; i < num_events; i++) {
> +               struct rte_event *event = &events[i];
> +               int handler_idx;
> +
> +               handler_idx = evd_lookup_handler_idx(lcore, event);
> +
> +               if (unlikely(handler_idx < 0)) {
> +                       drop_count++;
> +                       continue;
> +               }
> +
> +               bursts[handler_idx][burst_lens[handler_idx]] = *event;

Looks like it caching the event to accumulate ? If flow or queue is
configured as RTE_SCHED_TYPE_ORDERED?
Will it completely lose ordering as next rte_event_enqueue_burst will
release context?


Definition of RTE_SCHED_TYPE_ORDERED

#define RTE_SCHED_TYPE_ORDERED          0
/**< Ordered scheduling
 *
 * Events from an ordered flow of an event queue can be scheduled to multiple
 * ports for concurrent processing while maintaining the original event order.
 * This scheme enables the user to achieve high single flow throughput by
 * avoiding SW synchronization for ordering between ports which bound to cores.
 *
 * The source flow ordering from an event queue is maintained when events are
 * enqueued to their destination queue within the same ordered flow context.
 * An event port holds the context until application call
 * rte_event_dequeue_burst() from the same port, which implicitly releases
 * the context.
 * User may allow the scheduler to release the context earlier than that
 * by invoking rte_event_enqueue_burst() with RTE_EVENT_OP_RELEASE operation.
 *
 * Events from the source queue appear in their original order when dequeued
 * from a destination queue.
 * Event ordering is based on the received event(s), but also other
 * (newly allocated or stored) events are ordered when enqueued within the same
 * ordered context. Events not enqueued (e.g. released or stored) within the
 * context are  considered missing from reordering and are skipped at this time
 * (but can be ordered again within another context).
 *
 * @see rte_event_queue_setup(), rte_event_dequeue_burst(), RTE_EVENT_OP_RELEASE
 */