From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <dev-bounces@dpdk.org> Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 3D75642C4D; Wed, 7 Jun 2023 14:46:27 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 1491A40A84; Wed, 7 Jun 2023 14:46:27 +0200 (CEST) Received: from mail-ot1-f46.google.com (mail-ot1-f46.google.com [209.85.210.46]) by mails.dpdk.org (Postfix) with ESMTP id 075CE40698 for <dev@dpdk.org>; Wed, 7 Jun 2023 14:46:26 +0200 (CEST) Received: by mail-ot1-f46.google.com with SMTP id 46e09a7af769-6b29c972e00so1087259a34.1 for <dev@dpdk.org>; Wed, 07 Jun 2023 05:46:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1686141985; x=1688733985; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=FeTsFdvkikyJitS1uTEVofj70gWqoueCjHCSvmfLWqk=; b=PAMB+fRehnhbBJQu5TSybFqAXHRr70yXq+v1J8IaipNPz5QZkxWj2HgTS0T2DHbf7f ux6MIlB88dsyiotckYr294rNFAr2FYt18MbD5iMr61/ejlV+L7qO8BYUAXLi0TZGxYFk QvWWieEaPQl3zt22AmtLZ8MhiAH29Z0sKOJmzhfoZVtJBWUYbPLYSWNeAAY6IxuIIp1o 8eFi4Ii+qMczmzbYOA4xnNPZ+DKrgu9aAsuZ+msNZ5tIW3bQOaJHEKnZG+BLZGqI2fCY rWHF11F3hS1f2uZt0Bf+L6rEOdXFY6bP6z43w04CiwLij63+jafxOdjUVZVaSwIPIk35 YuKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686141985; x=1688733985; h=content-transfer-encoding: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=FeTsFdvkikyJitS1uTEVofj70gWqoueCjHCSvmfLWqk=; b=SM/xWbxJiAxKLBXf1gjZfudHWUmBdb03pQBWIzYbfWmDhSl9+Qr26ScXWBpxSEHteM tYomn+Mb47fWm1G9KlRp9BAIEGHymDRvkLR30GQQ7l/hHtpdXk4XR57nMssAyzfFGcso HLVJa2PRB3tNfVQaXbLOzqZ0f01QpQQ5s3FEM/Y2HdD/QrnwypGWEfPLLd6Fz5IX3BAg OhHh8pTFhsWisTx6PfIUNq+8qBSD6Mkw1YSW/Xx9Mzal9uOwZslyV9y6SMbHuyL1TAcR YDbheJ1PuoP3zqu4ZRHWqJE/+K9yTRbX3W0C0IncTI/Epp3VUHh1Qx/3HJtHQ9JBzHwz lWxg== X-Gm-Message-State: AC+VfDwZ9VjjaTblOcb8X78urS67ZTEfil0jXZ7qYYLqjwE6NI6oyMCp 2CxvLRHPPax+i4G7LhHUYkkXvJWOQ83JNqdtkoE= X-Google-Smtp-Source: ACHHUZ4gH/MMdBzUSj4zWHnJL1AZNQoPhGWfHXxuu7XhCmi0ZZO4E9kjam54t9BooR2GH7Dm2zIIWkfZO3Ni3xRFtBM= X-Received: by 2002:a05:6871:555:b0:196:4cb3:7b7 with SMTP id t21-20020a056871055500b001964cb307b7mr4591252oal.43.1686141985087; Wed, 07 Jun 2023 05:46:25 -0700 (PDT) MIME-Version: 1.0 References: <20230606144746.708388-1-zhirun.yan@intel.com> <20230607035144.1214492-1-zhirun.yan@intel.com> <20230607035144.1214492-18-zhirun.yan@intel.com> In-Reply-To: <20230607035144.1214492-18-zhirun.yan@intel.com> From: Jerin Jacob <jerinjacobk@gmail.com> Date: Wed, 7 Jun 2023 18:15:58 +0530 Message-ID: <CALBAE1O46V4f1ii6tGKfNKu9QzbpONq5bR80LMC8r3-sOh9gaQ@mail.gmail.com> Subject: Re: [PATCH v9 17/17] doc: update multicore dispatch model in graph guides To: Zhirun Yan <zhirun.yan@intel.com> Cc: dev@dpdk.org, jerinj@marvell.com, kirankumark@marvell.com, ndabilpuram@marvell.com, stephen@networkplumber.org, pbhagavatula@marvell.com, cunming.liang@intel.com, haiyue.wang@intel.com, mattias.ronnblom@ericsson.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions <dev.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> Errors-To: dev-bounces@dpdk.org On Wed, Jun 7, 2023 at 9:30=E2=80=AFAM Zhirun Yan <zhirun.yan@intel.com> wr= ote: > > Update graph documentation to introduce new multicore dispatch model. Please squash this to relevant implementation patches, No need for separate patch. This is the contribution guideline followed. > > Signed-off-by: Haiyue Wang <haiyue.wang@intel.com> > Signed-off-by: Cunming Liang <cunming.liang@intel.com> > Signed-off-by: Zhirun Yan <zhirun.yan@intel.com> > --- > doc/guides/prog_guide/graph_lib.rst | 68 +++++++++++++++++++++++++++-- > 1 file changed, 64 insertions(+), 4 deletions(-) > > diff --git a/doc/guides/prog_guide/graph_lib.rst b/doc/guides/prog_guide/= graph_lib.rst > index 1cfdc86433..8c2c2816ed 100644 > --- a/doc/guides/prog_guide/graph_lib.rst > +++ b/doc/guides/prog_guide/graph_lib.rst > @@ -189,14 +189,74 @@ In the above example, A graph object will be create= d with ethdev Rx > node of port 0 and queue 0, all ipv4* nodes in the system, > and ethdev tx node of all ports. > > -Multicore graph processing > -~~~~~~~~~~~~~~~~~~~~~~~~~~ > -In the current graph library implementation, specifically, > -``rte_graph_walk()`` and ``rte_node_enqueue*`` fast path API functions > +Graph models chossing Graph models > +~~~~~~~~~~~~~~~~~~~~~ > +Currently, there are 2 different walking models. Use macro > +RTE_GRAPH_MODEL_SELECT to set the model in compile time. Also offers the > +ability to choose models in runtime by not defining RTE_GRAPH_MODEL_SELECT. > +For application, must #define RTE_GRAPH_MODEL_SELECT before including > +rte_graph_worker.h Some rewording as suggestion. Graph models ~~~~~~~~~~~~ There are two different kinds of graph walking models. User can select the model using ``rte_graph_worker_model_set()`` API. If the application decides to use only one model, the fast path check can be avoided by defining the model with RTE_GRAPH_MODEL_SELECT. For example: .. code-block:: console #define RTE_GRAPH_MODEL_SELECT RTE_GRAPH_MODEL_RTC #include "rte_graph_worker.h" > + > +In l3fwd-graph, set RTE_GRAPH_MODEL_SELECT as the model explicitly for > +performance-sensitive use case. > +Or set the macro as GRAPH_MODEL_MCORE_RUNTIME_SELECT. And parse > +``"--model=3DNAME"`` in cmdline and use ``rte_graph_worker_model_set()`` > +to set the walking model in runtime. Please move to doc/guides/sample_app_ug/l3_forward_graph.rst > + > +RTC (Run-To-Completion) > +^^^^^^^^^^^^^^^^^^^^^^^ > +This is the default graph walking model. Specifically, > +``rte_graph_walk_rtc()`` and ``rte_node_enqueue*`` fast path API functio= ns > are designed to work on single-core to have better performance. > The fast path API works on graph object, So the multi-core graph > processing strategy would be to create graph object PER WORKER. > > +Example: > + > +Graph: node-0 -> node-1 -> node-2 @Core0. > + > +.. code-block:: diff > + > + + - - - - - - - - - - - - - - - - - - - - - + > + ' Core #0 ' > + ' ' > + ' +--------+ +---------+ +--------+ ' > + ' | Node-0 | --> | Node-1 | --> | Node-2 | ' > + ' +--------+ +---------+ +--------+ ' > + ' ' > + + - - - - - - - - - - - - - - - - - - - - - + > + > +Dispatch model > +^^^^^^^^^^^^^^ > +The dispatch model enables a cross-core dispatching mechanism which empl= oys > +a scheduling work-queue to dispatch streams to other worker cores which > +being associated with the destination node. > + > +Use ``rte_graph_model_mcore_dispatch_lcore_affinity_set()`` to set lcore= affinity > +with the node. > +Each worker core will have a graph repetition. Use ``rte_graph_clone()``= to clone > +graph for each worker and use``rte_graph_model_mcore_dispatch_core_bind(= )`` to > +bind graph with the worker core. > + > +Example: > + > +Graph topo: node-0 -> Core1; node-1 -> node-2; node-2 -> node-3. > +Config graph: node-0 @Core0; node-1/3 @Core1; node-2 @Core2. > + > +.. code-block:: diff > + > + + - - - - - -+ +- - - - - - - - - - - - - + + - - - - - -+ > + ' Core #0 ' ' Core #1 ' ' Core #2 ' > + ' ' ' ' ' ' > + ' +--------+ ' ' +--------+ +--------+ ' ' +--------+ ' > + ' | Node-0 | - - - ->| Node-1 | | Node-3 |<- - - - | Node-2 | ' > + ' +--------+ ' ' +--------+ +--------+ ' ' +--------+ ' > + ' ' ' | ' ' ^ ' > + + - - - - - -+ +- - -|- - - - - - - - - - + + - - -|- - -+ > + | | > + + - - - - - - - - - - - - - - - - + > + > + > In fast path > ~~~~~~~~~~~~ > Typical fast-path code looks like below, where the application > -- > 2.37.2 >