> -----Original Message-----
> From: Jerin Jacob <jerinjac...@gmail.com>
> Sent: Thursday, March 2, 2023 9:58 PM
> To: Yan, Zhirun <zhirun....@intel.com>
> Cc: dev@dpdk.org; jer...@marvell.com; kirankum...@marvell.com;
> ndabilpu...@marvell.com; Liang, Cunming <cunming.li...@intel.com>; Wang,
> Haiyue <haiyue.w...@intel.com>
> Subject: Re: [PATCH v1 04/13] graph: add get/set graph worker model APIs
>
> On Thu, Mar 2, 2023 at 2:09 PM Yan, Zhirun <zhirun....@intel.com> wrote:
> >
> >
> >
> > > -----Original Message-----
> > > From: Jerin Jacob <jerinjac...@gmail.com>
> > > Sent: Monday, February 27, 2023 6:23 AM
> > > To: Yan, Zhirun <zhirun....@intel.com>
> > > Cc: dev@dpdk.org; jer...@marvell.com; kirankum...@marvell.com;
> > > ndabilpu...@marvell.com; Liang, Cunming <cunming.li...@intel.com>;
> > > Wang, Haiyue <haiyue.w...@intel.com>
> > > Subject: Re: [PATCH v1 04/13] graph: add get/set graph worker model
> > > APIs
> > >
> > > On Fri, Feb 24, 2023 at 12:01 PM Yan, Zhirun <zhirun....@intel.com> wrote:
> > > >
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Jerin Jacob <jerinjac...@gmail.com>
> > > > > Sent: Monday, February 20, 2023 9:51 PM
> > > > > To: Yan, Zhirun <zhirun....@intel.com>
> > > > > Cc: dev@dpdk.org; jer...@marvell.com; kirankum...@marvell.com;
> > > > > ndabilpu...@marvell.com; Liang, Cunming
> > > > > <cunming.li...@intel.com>; Wang, Haiyue <haiyue.w...@intel.com>
> > > > > Subject: Re: [PATCH v1 04/13] graph: add get/set graph worker
> > > > > model APIs
> > > > >
> > > > > On Thu, Nov 17, 2022 at 10:40 AM Zhirun Yan
> > > > > <zhirun....@intel.com>
> > > wrote:
> > > > > >
> > > > > > Add new get/set APIs to configure graph worker model which is
> > > > > > used to determine which model will be chosen.
> > > > > >
> > > > > > Signed-off-by: Haiyue Wang <haiyue.w...@intel.com>
> > > > > > Signed-off-by: Cunming Liang <cunming.li...@intel.com>
> > > > > > Signed-off-by: Zhirun Yan <zhirun....@intel.com>
> > > > > > ---
> > > > > > lib/graph/rte_graph_worker.h | 51
> > > +++++++++++++++++++++++++++++
> > > > > > lib/graph/rte_graph_worker_common.h | 13 ++++++++
> > > > > > lib/graph/version.map | 3 ++
> > > > > > 3 files changed, 67 insertions(+)
> > > > > >
> > > > > > diff --git a/lib/graph/rte_graph_worker.h
> > > > > > b/lib/graph/rte_graph_worker.h index 54d1390786..a0ea0df153
> > > 100644
> > > > > > --- a/lib/graph/rte_graph_worker.h
> > > > > > +++ b/lib/graph/rte_graph_worker.h
> > > > > > @@ -1,5 +1,56 @@
> > > > > > #include "rte_graph_model_rtc.h"
> > > > > >
> > > > > > +static enum rte_graph_worker_model worker_model =
> > > > > > +RTE_GRAPH_MODEL_DEFAULT;
> > > > >
> > > > > This will break the multiprocess.
> > > >
> > > > Thanks. I will use TLS for per-thread local storage.
> > >
> > > If it needs to be used from secondary process, then it needs to be
> > > from memzone.
> > >
> >
> >
> > This filed will be set by primary process in initial stage, and then lcore
> > will only
> read it.
> > I want to use RTE_DEFINE_PER_LCORE to define the worker model here. It
> > seems not necessary to allocate from memzone.
> >
> > >
> > >
> > > >
> > > > >
> > > > > > +
> > > > > > +/** Graph worker models */
> > > > > > +enum rte_graph_worker_model { #define WORKER_MODEL_DEFAULT
> > > > > > +"default"
> > > > >
> > > > > Why need strings?
> > > > > Also, every symbol in a public header file should start with
> > > > > RTE_ to avoid namespace conflict.
> > > >
> > > > It was used to config the model in app. I can put the string into
> > > > example.
> > >
> > > OK
> > >
> > > >
> > > > >
> > > > > > + RTE_GRAPH_MODEL_DEFAULT = 0, #define
> WORKER_MODEL_RTC
> > > > > > +"rtc"
> > > > > > + RTE_GRAPH_MODEL_RTC,
> > > > >
> > > > > Why not RTE_GRAPH_MODEL_RTC = RTE_GRAPH_MODEL_DEFAULT in
> > > enum
> > > > > itself.
> > > > Yes, will do in next version.
> > > >
> > > > >
> > > > > > +#define WORKER_MODEL_GENERIC "generic"
> > > > >
> > > > > Generic is a very overloaded term. Use pipeline here i.e
> > > > > RTE_GRAPH_MODEL_PIPELINE
> > > >
> > > > Actually, it's not a purely pipeline mode. I prefer to change to hybrid.
> > >
> > > Hybrid is very overloaded term, and it will be confusing
> > > (considering there will be new models in future).
> > > Please pick a word that really express the model working.
> > >
> >
> > In this case, the path is Node0 -> Node1 -> Node2 -> Node3 And Node1
> > and Node3 are binding with one core.
> >
> > Our model offers the ability to dispatch between cores.
> >
> > Do you think RTE_GRAPH_MODEL_DISPATCH is a good name?
>
> Some names, What I can think of
>
> // MCORE->MULTI CORE
>
> RTE_GRAPH_MODEL_MCORE_PIPELINE
> or
> RTE_GRAG_MODEL_MCORE_DISPATCH
> or
> RTE_GRAG_MODEL_MCORE_RING
> or
> RTE_GRAPH_MODEL_MULTI_CORE
>
Thanks, I will use RTE_GRAG_MODEL_MCORE_DISPATCH as the name.
> >
> > + - - - - - -+ +- - - - - - - - - - - - - + + - - - - - -+
> > ' Core #0 ' ' Core #1 Core #1 ' ' Core #2 '
> > ' ' ' ' ' '
> > ' +--------+ ' ' +--------+ +--------+ ' ' +--------+ '
> > ' | Node-0 | - - - ->| Node-1 | | Node-3 |<- - - - | Node-2 | '
> > ' +--------+ ' ' +--------+ +--------+ ' ' +--------+ '
> > ' ' ' | ' ' ^ '
> > + - - - - - -+ +- - -|- - - - - - - - - - + + - - -|- - -+
> > | |
> > + - - - - - - - - - - - - - - - - +
> >
> >
> > > > >
> > > > >
> > > > > > + RTE_GRAPH_MODEL_GENERIC,
> > > > > > + RTE_GRAPH_MODEL_MAX,
> > > > >
> > > > > No need for MAX, it will break the ABI for future. See other
> > > > > subsystem such as cryptodev.
> > > >
> > > > Thanks, I will change it.
> > > > >
> > > > > > +};
> > > > >
> > > > > >
