From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 7E79C41CEC; Mon, 20 Feb 2023 15:17:55 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 6EC3043066; Mon, 20 Feb 2023 15:17:55 +0100 (CET) Received: from mail-vs1-f53.google.com (mail-vs1-f53.google.com [209.85.217.53]) by mails.dpdk.org (Postfix) with ESMTP id 972FA40395 for ; Mon, 20 Feb 2023 15:17:53 +0100 (CET) Received: by mail-vs1-f53.google.com with SMTP id y8so8217vsn.2 for ; Mon, 20 Feb 2023 06:17:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1676902672; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=ZgFe3Y8gBLVMY3f5H9X7M5ZaRYM/i5olnIE+kTtLyJ8=; b=lWkk9ZwOiqmWafYHw8weFFt0vhqS5Yds+MJO8X7O4o6N+WrcLFnDjeDevVXCHw4vOp NR7ztyMAoLFs7TXwfr0u9LSqIx+iId6FPsYje6TjdKQMSr3ZqBlK0jRHRLoCwBuxKAZs B1oj9BDg2ueqIWPcqruJwmReJy+Pb2mS0ZwVkakC+SWIbz4gZweG25ZUyLewYKABwNqg VtbCStD4GD4aHn+mPTmx49lMCE3HiYh6BZzZwE+g2hiRMrLdd8l7StFd+luTkRYDuGeA yfYWL7+CvhuKOIz3OqAbCb6gxXcGm+L4i+X8ZW1nyV25RVe3ndAY479pFglgfDNp/xmC OYDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1676902672; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=ZgFe3Y8gBLVMY3f5H9X7M5ZaRYM/i5olnIE+kTtLyJ8=; b=gnUdP4MqKLzbFVLUBENsomrJJxT52r9tiqOTOJmZaymGK1ebzWrsw/AV361YgueJK2 /h6c3JcgPgeQIobJ1ZjX1oPJQSQZdhP+DhbO0UCPNfQPaJgeDZNPMdyjtGdJtZNZiz+m ZGw7tQK+qAXdxziTYDlLkQ+E5gCZd96waoL+GmzhgLnQD23mI8HXF9x4Q89IE1rIg6AJ T1Cc0wtanRAj5/cmO0cegiOLlqblBXUGKulGIwesRupibvIumx+9YQeC9HSPoyBCmAd4 Ew+MuZWnDSQBpTo388V87IYlFpEy/j1NAOb1QscAUwSLGxE6Xu3IbZbuhPnOHh9E4fZ8 2buQ== X-Gm-Message-State: AO0yUKV1EnfPbidBRQxW9RLpYHXbyjovwc1dh6NUEeSVmPTuw29OasYu dB2HwwgCViBe24t27v+FUe07L5Evoe17VdKYHHM= X-Google-Smtp-Source: AK7set+GZU0nimMQSrD5MokE8ebWu9eyuP8gpKvbXWpNyy0pToE65BsBqK47HVXwhpNnlVlGw1sjt9djpDZ3qDhPiCE= X-Received: by 2002:a05:6102:38d4:b0:3f0:89e1:7c80 with SMTP id k20-20020a05610238d400b003f089e17c80mr285763vst.72.1676902672615; Mon, 20 Feb 2023 06:17:52 -0800 (PST) MIME-Version: 1.0 References: <20221117050926.136974-1-zhirun.yan@intel.com> <20221117050926.136974-9-zhirun.yan@intel.com> In-Reply-To: <20221117050926.136974-9-zhirun.yan@intel.com> From: Jerin Jacob Date: Mon, 20 Feb 2023 19:47:26 +0530 Message-ID: Subject: Re: [PATCH v1 08/13] graph: introduce stream moving cross cores To: Zhirun Yan Cc: dev@dpdk.org, jerinj@marvell.com, kirankumark@marvell.com, ndabilpuram@marvell.com, cunming.liang@intel.com, haiyue.wang@intel.com Content-Type: text/plain; charset="UTF-8" X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On Thu, Nov 17, 2022 at 10:40 AM Zhirun Yan 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 > @@ -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. > /* Fast path area */ > #define RTE_NODE_CTX_SZ 16 > uint8_t ctx[RTE_NODE_CTX_SZ] __rte_cache_aligned; /**< Node Context. */ > -- > 2.25.1 >