On Thu, Feb 8, 2024 at 3:20 PM Mattias Rönnblom <hof...@lysator.liu.se> wrote:
>
> On 2024-02-07 11:14, Jerin Jacob wrote:
> > On Fri, Feb 2, 2024 at 7:29 PM Bruce Richardson
> > <bruce.richard...@intel.com> wrote:
> >>
> >> Make some textual improvements to the introduction to eventdev and event
> >> devices in the eventdev header file. This text appears in the doxygen
> >> output for the header file, and introduces the key concepts, for
> >> example: events, event devices, queues, ports and scheduling.
> >>
> >> This patch makes the following improvements:
> >> * small textual fixups, e.g. correcting use of singular/plural
> >> * rewrites of some sentences to improve clarity
> >> * using doxygen markdown to split the whole large block up into
> >> sections, thereby making it easier to read.
> >>
> >> No large-scale changes are made, and blocks are not reordered
> >>
> >> Signed-off-by: Bruce Richardson <bruce.richard...@intel.com>
> >
> > Thanks Bruce, While you are cleaning up, Please add following or
> > similar change to fix for not properly
> > parsing the struct rte_event_vector. i.e it is coming as global
> > variables in html files.
> >
> > l[dpdk.org] $ git diff
> > diff --git a/lib/eventdev/rte_eventdev.h b/lib/eventdev/rte_eventdev.h
> > index e31c927905..ce4a195a8f 100644
> > --- a/lib/eventdev/rte_eventdev.h
> > +++ b/lib/eventdev/rte_eventdev.h
> > @@ -1309,9 +1309,9 @@ struct rte_event_vector {
> > */
> > struct {
> > uint16_t port;
> > - /* Ethernet device port id. */
> > + /**< Ethernet device port id. */
> > uint16_t queue;
> > - /* Ethernet device queue id. */
> > + /**< Ethernet device queue id. */
> > };
> > };
> > /**< Union to hold common attributes of the vector array. */
> > @@ -1340,7 +1340,11 @@ struct rte_event_vector {
> > * vector array can be an array of mbufs or pointers or opaque u64
> > * values.
> > */
> > +#ifndef __DOXYGEN__
> > } __rte_aligned(16);
> > +#else
> > +};
> > +#endif
> >
> > /* Scheduler type definitions */
> > #define RTE_SCHED_TYPE_ORDERED 0
> >
> >>
> >> ---
> >> V3: reworked following feedback from Mattias
> >> ---
> >> lib/eventdev/rte_eventdev.h | 132 ++++++++++++++++++++++--------------
> >> 1 file changed, 81 insertions(+), 51 deletions(-)
> >>
> >> diff --git a/lib/eventdev/rte_eventdev.h b/lib/eventdev/rte_eventdev.h
> >> index ec9b02455d..a741832e8e 100644
> >> --- a/lib/eventdev/rte_eventdev.h
> >> +++ b/lib/eventdev/rte_eventdev.h
> >> @@ -12,25 +12,33 @@
> >> * @file
> >> *
> >> * RTE Event Device API
> >> + * ====================
> >> *
> >> - * In a polling model, lcores poll ethdev ports and associated rx queues
> >> - * directly to look for packet. In an event driven model, by contrast,
> >> lcores
> >> - * call the scheduler that selects packets for them based on programmer
> >> - * specified criteria. Eventdev library adds support for event driven
> >> - * programming model, which offer applications automatic multicore
> >> scaling,
> >> - * dynamic load balancing, pipelining, packet ingress order maintenance
> >> and
> >> - * synchronization services to simplify application packet processing.
> >> + * In a traditional run-to-completion application model, lcores pick up
> >> packets
> >
> > Can we keep it is as poll mode instead of run-to-completion as event mode
> > also
> > supports run to completion by having dequuee() and then Tx.
> >
>
> A "traditional" DPDK app is both polling and run-to-completion. You
> could always add "polling" somewhere, but "run-to-completion" in that
> context serves a purpose, imo.
Yeah. Some event devices can actually sleep to save power if packet is
not present(using WFE in arm64 world).
I think, We can be more specific then, like
In a traditional run-to-completion application model where packet are
dequeued from NIC RX queues, .......
>
> A single-stage eventdev-based pipeline will also process packets in a
> run-to-completion fashion. In such a scenario, the difference between
> eventdev and the "tradition" lies in the (ingress-only) load balancing
> mechanism used (which the below note on the "traditional" use of RSS
> indicates).
