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 27B3743095; Fri, 18 Aug 2023 08:10:11 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id A71BC40ED9; Fri, 18 Aug 2023 08:10:10 +0200 (CEST) Received: from mail-ua1-f46.google.com (mail-ua1-f46.google.com [209.85.222.46]) by mails.dpdk.org (Postfix) with ESMTP id 3A9AD40395; Fri, 18 Aug 2023 08:10:10 +0200 (CEST) Received: by mail-ua1-f46.google.com with SMTP id a1e0cc1a2514c-79a31d66002so202462241.3; Thu, 17 Aug 2023 23:10:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1692339009; x=1692943809; 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=p0YR3DjrVRgmwRBT3GkqEj/jZUmZ5xxlUm8dmTpZ5qc=; b=kzdMYyDsr7v/eBWN3lzqnJdfXUzZFVRyBu1OnIroiOVPnB4kNFuc1MzluPmzS+0mcR cwdbbML8304nIzTGqchAD3gZQdFyE9NNi5m91O3AkeX0OPHOX7tGJpc6Y/AA7zciCRwg 1n2Dc2+ZksgmkvGhivCvYOQZKnfKrjSnFWMybPf/zZwWFp7851a+0jcRUAVC2ZDvdKct A9l236xQljfeTYt/ORcXtsP9zn6jO0ose74SQKH5HMiF3bBH+Gvei6JYFghXZ3zzESIM Q4fR/iiYpBwjNxbCHU/v+HM/wwsti+FcXnq+YbNsOS5tWMXqKupIVxptO8eRWbx3UuME MRTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1692339009; x=1692943809; 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=p0YR3DjrVRgmwRBT3GkqEj/jZUmZ5xxlUm8dmTpZ5qc=; b=mG5JK3ayoqBfvPC69g8KrAgALC+IJdrpmaFK4y0f+Ye3jkcdOX13UOx1phfDmSoDQJ CtQb6cNIpIY0LfHrewjhPVh0egptaIaOKuHTFb6WB9JByEk06Sk8k7lCklncQFjsOxQM vP3XdHvaTZ9A2JVVLH1/mgDMgrw4Fypewv1KpkzDpCu398FrkVFAHzK15mSqvAb3HwXF NzkZ+a55eHy+lrxlbhFiURffgKN4tEk8rAH2bTwDqw4llQR5M4gnzJZpMOV8OcRuRW1M hyIaEgtGueoUrAvRuDKHykoA5N+fz4lAhY0d2vRNJSejMa9qmJOcAsLmKAnflQ1U14Bd 4cGA== X-Gm-Message-State: AOJu0Yx42+MSx2rXQRgIq/EkdtuVrzutU5GIRcd5dN32Fbj6B54haWnl jWMVICGG7QKJQbi/VcQH/ukNyIcOweMjiqYxCQI= X-Google-Smtp-Source: AGHT+IHVYBYfZSSCkNe9PQ+THsWtCBWS4ytt0VDaaJA9xLoI/tVnqhXbSxRjp2GMnuuaHAuiIscdJftgGrgqzBjZD/o= X-Received: by 2002:a67:cf07:0:b0:443:5aca:d2dc with SMTP id y7-20020a67cf07000000b004435acad2dcmr2232644vsl.6.1692339009394; Thu, 17 Aug 2023 23:10:09 -0700 (PDT) MIME-Version: 1.0 References: <20230614172527.157664-2-mattias.ronnblom@ericsson.com> <20230616074041.159675-1-mattias.ronnblom@ericsson.com> <20230616074041.159675-2-mattias.ronnblom@ericsson.com> In-Reply-To: <20230616074041.159675-2-mattias.ronnblom@ericsson.com> From: Jerin Jacob Date: Fri, 18 Aug 2023 11:39:43 +0530 Message-ID: Subject: Re: [PATCH v2 1/3] eventdev: introduce event dispatcher To: =?UTF-8?Q?Mattias_R=C3=B6nnblom?= Cc: jerinj@marvell.com, hofors@lysator.liu.se, dev@dpdk.org, harry.van.haaren@intel.com, peter.j.nilsson@ericsson.com, Stephen Hemminger , Heng Wang , "Naga Harish K, S V" , Erik Gabriel Carrillo , "Gujjar, Abhinandan S" , Pavan Nikhilesh , Shijith Thotton , Hemant Agrawal , Sachin Saxena , Liang Ma , Peter Mccarthy , techboard@dpdk.org, Zhirun Yan 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On Fri, Jun 16, 2023 at 1:17=E2=80=AFPM Mattias R=C3=B6nnblom wrote: > > The purpose of the event dispatcher is to help reduce coupling in an > Eventdev-based DPDK application. > > In addition, the event dispatcher also provides a convenient and > flexible way for the application to use service cores for > application-level processing. > > Signed-off-by: Mattias R=C3=B6nnblom > Tested-by: Peter Nilsson > Reviewed-by: Heng Wang Adding eventdev maintainers and tech board, Hi Mattais, Finally, got some time to review this series, and thanks for excellent documentation. I understand the use case for the dispatcher, But following are some of my concern 1) To decouple the application specific business logic, one need to use two function pointers to access per packet (match and process) function. 2) Need to enforce service core for its usage. IMO, Both are a given application's choice, All the application does not need to use this scheme. Keeping the code in lib/eventdev has the following issue. 1)It is kind of enforcing above scheme for all the application modeling, which may not applicable for application use cases and eventdev device does not dictate a specific framework model. 2) The framework code, we never kept in device class library. i.e., public APIs are implemented through device class API and public API don't have any no hook to PMD API. For example, we never kept lib/distributor/ code in lib/ethdev. Other than the placement of this code, I agree with use case and solution at high level . The following could option for placement of this library. Based on that, we can have next level review. 1) It is possible to plug in this to lib/graph by adding new graph model(@zhirun.yan@intel.com recently added RTE_GRAPH_MODEL_MCORE_DISPATCH) Based on my understanding, That can translate to a) Adding new graph model which allows to have it on graph walk (Graph walk is nothing but calling registered dispatcher routines) b) It is possible to add model specific APIs via rte_graph_model_model_name_xxxx() c) Graph library is not using match callback kind of scheme. Instead, nodes will process the packet and find its downstream node and enqueue to it and then graph_walk() calls the downstream node specific process function. With that, we can meet the original goal of business logic decoupling. However, Currently, nodes are not aware of what kind of graph model it is running, that could be one issue here as eventdev has more scheduling properties like schedule type etc., to overcome that issue, it may be possible to introduce nodes to graph model compatibility (where nodes can advertise the supported graph models) d) Currently we are planning to make graph API as stable, if we are taking this path, we need to hold https://patches.dpdk.org/project/dpdk/patch/20230810180515.113700-1-stephen= @networkplumber.org/ as we may need to update some public APIs. 2) Have new library lib/event_dispatcher 3) Move to example directory to showcase the framework 4) Move to app/test-eventdev directory to show the case of the framework. Thoughts?