[PATCH v1 08/13] graph: introduce stream moving cross cores
Yan, Zhirun
zhirun.yan at intel.com
Fri Feb 24 07:48:33 CET 2023
> -----Original Message-----
> From: Jerin Jacob <jerinjacobk at gmail.com>
> Sent: Monday, February 20, 2023 10:17 PM
> To: Yan, Zhirun <zhirun.yan at intel.com>
> Cc: dev at dpdk.org; jerinj at marvell.com; kirankumark at marvell.com;
> ndabilpuram at marvell.com; Liang, Cunming <cunming.liang at intel.com>; Wang,
> Haiyue <haiyue.wang at intel.com>
> Subject: Re: [PATCH v1 08/13] graph: introduce stream moving cross cores
>
> On Thu, Nov 17, 2022 at 10:40 AM Zhirun Yan <zhirun.yan at intel.com> wrote:
> >
> > This patch introduces key functions to allow a worker thread to enable
> > enqueue and move streams of objects to the next nodes over different
> > cores.
> >
> > 1. add graph_sched_wq_node to hold graph scheduling workqueue node
> > stream 2. add workqueue help functions to
> > create/destroy/enqueue/dequeue
>
> Two things, make as two patches
>
I will do in next version.
>
> > @@ -39,6 +46,15 @@ struct rte_graph {
> > uint32_t cir_mask; /**< Circular buffer wrap around mask. */
> > rte_node_t nb_nodes; /**< Number of nodes in the graph. */
> > rte_graph_off_t *cir_start; /**< Pointer to circular buffer.
> > */
> > + /* Graph schedule */
> > + struct rte_graph_rq_head *rq __rte_cache_aligned; /* The run-queue */
> > + struct rte_graph_rq_head rq_head; /* The head for run-queue
> > + list */
> > +
> > + SLIST_ENTRY(rte_graph) rq_next; /* The next for run-queue list */
> > + unsigned int lcore_id; /**< The graph running Lcore. */
> > + struct rte_ring *wq; /**< The work-queue for pending streams. */
> > + struct rte_mempool *mp; /**< The mempool for scheduling streams. */
> > + /* Graph schedule area */
> > rte_graph_off_t nodes_start; /**< Offset at which node memory starts.
> */
> > rte_graph_t id; /**< Graph identifier. */
> > int socket; /**< Socket ID where memory is allocated. */
> > @@ -63,6 +79,8 @@ struct rte_node {
> > char parent[RTE_NODE_NAMESIZE]; /**< Parent node name. */
> > char name[RTE_NODE_NAMESIZE]; /**< Name of the node. */
> >
> > + /* Fast schedule area */
> > + unsigned int lcore_id __rte_cache_aligned; /**< Node running
> > + Lcore. */
>
> Do we need __rte_cache_aligned here? I am wondering can we add union for
> different model specific area ONLY for fast path so that we can save memory
> and fast path data will be more warm.
Maybe it is not necessary. I agree with you and I can use union to cover the specific field.
>
> > /* Fast path area */
> > #define RTE_NODE_CTX_SZ 16
> > uint8_t ctx[RTE_NODE_CTX_SZ] __rte_cache_aligned; /**< Node
> > Context. */
> > --
> > 2.25.1
> >
More information about the dev
mailing list