[EXTERNAL] Re: [PATCH v5 0/6] Introduce event pre-scheduling

[Pavan Nikhilesh Bhagavatula]

> > From: Pavan Nikhilesh <pbhagavatula at marvell.com>
> >
> > Event pre-scheduling improves scheduling performance by assigning events
> > to event ports in advance when dequeues are issued.
> > This series introduces various types and levels of pre-scheduling to the
> > eventdev library.
> >
> > pre-scheduling Types:
> >  * RTE_EVENT_PRESCHEDULE_NONE: No pre-scheduling.
> >  * RTE_EVENT_PRESCHEDULE: Always issue a pre-schedule when dequeue is
> issued.
> >  * RTE_EVENT_PRESCHEDULE_ADAPTIVE: Delay issuing pre-schedule until
> there
> >    are no forward progress constraints with the held flow contexts.
> >
> > pre-scheduling Levels:
> >  * Event Device Level Pre-scheduling: Pre-scheduling can be enabled or
> disabled at the
> >    event device during configuration. Event devices can indicate pre-
> scheduling
> >    capabilities using `RTE_EVENT_DEV_CAP_EVENT_PRESCHEDULE` and
> >   `RTE_EVENT_DEV_CAP_EVENT_PRESCHEDULE_ADAPTIVE` via the event
> device info
> >   function `info.event_dev_cap`.
> >  * Event Port Level Prefetch: Pre-scheduling can be selectively enabled or
> disabled
> >    at the event port during runtime. Event devices can indicate this capability
> >    using `RTE_EVENT_PORT_CAP_PER_PORT_PRESCHEDULE` via the event
> device info
> >    function `info.event_port_cap`.
> >  * Application Controlled Prefetch Hint: Applications can provide hints to the
> >    event device to start pre-scheduling events using the new API
> >    `rte_event_port_pre-schedule`. Event devices can indicate this capabilities
> using
> >    `RTE_EVENT_DEV_CAP_PRESCHEDULE_EXPLICIT` via the event device info
> function
> >    `info.event_dev_cap`.
> >
> > The rte_event_dequeue_burst operation initiates the pre-schedule
> operation, which
> > completes in parallel without affecting the flow context of the dequeued
> events and
> > dequeue latency. On the next dequeue operation, the pre-scheduleed events
> are
> > dequeued, and pre-schedule operation is initiated again.
> >
> > In the case of application-controlled pre-schedule hints, the currently held
> flow
> > contexts, if any, are not affected by the pre-schedule operation. On the next
> > dequeue operation, the pre-scheduleed events are returned, but pre-
> schedule is not
> > initiated again until the application provides the hint again. If pre-scheduling
> > is already enabled at the event device level or event port level, the hint is
> ignored.
> >
> > v2 Changes:
> > - s/prefetch/pre-schedule (Mattias).
> > v3 Changes:
> > - Add CNXK preschedule implementation.
> > - Update test-eventdev to use prescheduling.
> > - Update examples to use prescheduling.
> > v4 Changes:
> > - Fix compilation.
> > v5 Changes:
> > - Update ABI changes
> > - s/RTE_EVENT_DEV_PRESCHEDULE/RTE_EVENT_PRESCHEDULE/
> > -
> s/RTE_EVENT_DEV_CAP_SW_PRESCHEDULE/RTE_EVENT_DEV_CAP_PRESCHE
> DULE_EXPLICIT/
> > -
> s/RTE_EVENT_PORT_CAP_EVENT_PER_PORT_PRESCHEDULE/RTE_EVENT_PO
> RT_CAP_PER_PORT_PRESCHEDULE
> > - Various documentation fixes and updates.
> >
> >
> > Pavan Nikhilesh (6):
> >   eventdev: introduce event pre-scheduling
> >   eventdev: add event port pre-schedule modify
> >   eventdev: add event preschedule hint
> >   event/cnkx: add pre-schedule support
> >   app/test-eventdev: add pre-scheduling support
> >   examples: use eventdev pre-scheduling
> >
> >  app/test-eventdev/evt_common.h                |  45 +++--
> >  app/test-eventdev/evt_options.c               |  17 ++
> >  app/test-eventdev/evt_options.h               |   1 +
> >  app/test/test_eventdev.c                      | 143 ++++++++++++++++
> >  doc/guides/eventdevs/cnxk.rst                 |  10 --
> >  doc/guides/eventdevs/features/cnxk.ini        |   1 +
> >  doc/guides/eventdevs/features/default.ini     |   1 +
> >  doc/guides/prog_guide/eventdev/eventdev.rst   |  48 ++++++
> >  doc/guides/rel_notes/release_24_11.rst        |  13 ++
> >  doc/guides/tools/testeventdev.rst             |   6 +
> >  drivers/event/cnxk/cn10k_eventdev.c           |  19 ++-
> >  drivers/event/cnxk/cn10k_worker.c             |  21 +++
> >  drivers/event/cnxk/cn10k_worker.h             |   2 +
> >  drivers/event/cnxk/cnxk_eventdev.c            |   2 -
> >  drivers/event/cnxk/cnxk_eventdev.h            |   1 -
> >  .../pipeline_worker_generic.c                 |   6 +
> >  .../eventdev_pipeline/pipeline_worker_tx.c    |   6 +
> >  examples/ipsec-secgw/event_helper.c           |   6 +
> >  examples/l2fwd-event/l2fwd_event_generic.c    |   6 +
> >  .../l2fwd-event/l2fwd_event_internal_port.c   |   6 +
> >  examples/l3fwd/l3fwd_event_generic.c          |   6 +
> >  examples/l3fwd/l3fwd_event_internal_port.c    |   6 +
> >  lib/eventdev/eventdev_pmd.h                   |   4 +
> >  lib/eventdev/eventdev_private.c               |  41 ++++-
> >  lib/eventdev/eventdev_trace_points.c          |   6 +
> >  lib/eventdev/rte_eventdev.h                   | 159 ++++++++++++++++++
> >  lib/eventdev/rte_eventdev_core.h              |  14 +-
> >  lib/eventdev/rte_eventdev_trace_fp.h          |  19 ++-
> >  lib/eventdev/version.map                      |   6 +
> >  29 files changed, 592 insertions(+), 29 deletions(-)
> 
> Looks good, but the new API's should be experimental right?

Ah yes, my bad, Thanks Stephen, I will mark them as experimental in next version.