On Sat, Feb 10, 2024 at 08:24:29AM +0100, Mattias Rönnblom wrote:
> On 2024-02-09 09:43, Jerin Jacob wrote:
> > 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).
> >
>
> Sure, and I believe you can do that with certain Ethdevs as well. Also, you
> can also use interrupts. So polling/energy-efficient polling
> (wfe/umwait)/interrupts aren't really a differentiator between Eventdev and
> "raw" Ethdev.
>
> > 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, .......
> >
>
> "In a traditional DPDK application model, the application polls Ethdev port
> RX queues to look for work, and processing is done in a run-to-completion
> manner, after which the packets are transmitted on a Ethdev TX queue. Load
> is distributed by statically assigning ports and queues to lcores, and NIC
> receive-side scaling (RSS, or similar) is employed to distribute network
> flows (and thus work) on the same port across multiple RX queues."
>
> I don̈́'t know if that's too much.
>
Looks fine to me, I'll just use that text in V4.
