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 8DFCF430D0; Tue, 22 Aug 2023 14:33:15 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 2CE5D4021D; Tue, 22 Aug 2023 14:33:15 +0200 (CEST) Received: from mail-ua1-f53.google.com (mail-ua1-f53.google.com [209.85.222.53]) by mails.dpdk.org (Postfix) with ESMTP id CD78A40041; Tue, 22 Aug 2023 14:33:13 +0200 (CEST) Received: by mail-ua1-f53.google.com with SMTP id a1e0cc1a2514c-79a2216a22fso1475367241.0; Tue, 22 Aug 2023 05:33:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1692707593; x=1693312393; 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=PT2USJUk/1YLVaCA7Wse3DeLIFpUzE28ah58KbB8Z5I=; b=fLwXHYjtpfAHdUKZZfZ2cAo7FWuFLgvbpr7cMQiU2u3PbMmoK1iS4P3QprdcH5E5ey wjAGt755llLQrBi8VXoU5YZNJat3NHk93OimNAB5j7UKrQyg3w8y6GsHqHJ934vKT/uv fMevisN9MdCPJGU3vOfylCp+wl4JPTdpI9ng1YqzccsvX2iWIR1oyQAnmxbUdBprTdLl NO2dohSPgWlGlcVgsbU0BUoq9zhRMLlCcuZLPdN5Ed8IY289GXAgEb4/9nErFd6nCxnN oR2+4miyAEJwJEwzicT+XFkRIh6PRYSiwyyvWGLi9UzqZAIoVkxzTNaDz0vcwrX+PSFv /AUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1692707593; x=1693312393; 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=PT2USJUk/1YLVaCA7Wse3DeLIFpUzE28ah58KbB8Z5I=; b=VGvEydHn4hFkxR2l9AZdBMS+8TM0GeeSayK9CsWcfLJw/JfTuLdF6pV04VxAYeDO45 CBwLzCBQlE9HYJn+rWtda9R38nv8a58SnOkcbK0JxpnE/l3xpImHw6jaTt0tYeaMrKuz zKH9nl+wSyD8gkwE8YNc/JLq0ntvxOuUg1P1SntTtb0xCC8sIVs2xaH5GjzaEqJS+3w6 r9iHoCKjNfAP2G4PGJ8voNBZPdO2Olfa1+2RmI47GBIF/mOHTWMiDR5CrUCPUpJVdePn DpeScjhOVh4F2G/hGp73VPcEhsH0SKVaODJfAuDvMOrcjt8OWyEVaDicjFrI4Z+YOUlx BTiA== X-Gm-Message-State: AOJu0YydOOLQy3H6CmfkRA4tEdcabrag/HLWLJ8TWjy5UmfECJqCtFQ2 aSYLqw6W5ewwbkdEvkkckfZ3H/v9jOrrybSGFDc= X-Google-Smtp-Source: AGHT+IE/y5ckMgpm6NkgyxtwnuIyo5FxL2Hllduj6b0cpdexpckCfIvda/x19WMXkr7vywU2ZVFDIn4dMbIBbuKoMP4= X-Received: by 2002:a67:e9c8:0:b0:446:e025:fa61 with SMTP id q8-20020a67e9c8000000b00446e025fa61mr7109120vso.11.1692707592966; Tue, 22 Aug 2023 05:33:12 -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> <785e3e39-9258-8b87-7d9b-083a370a787b@lysator.liu.se> In-Reply-To: <785e3e39-9258-8b87-7d9b-083a370a787b@lysator.liu.se> From: Jerin Jacob Date: Tue, 22 Aug 2023 18:02:46 +0530 Message-ID: Subject: Re: [PATCH v2 1/3] eventdev: introduce event dispatcher To: =?UTF-8?Q?Mattias_R=C3=B6nnblom?= Cc: =?UTF-8?Q?Mattias_R=C3=B6nnblom?= , jerinj@marvell.com, 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 Tue, Aug 22, 2023 at 2:12=E2=80=AFPM Mattias R=C3=B6nnblom wrote: > > On 2023-08-18 08:09, Jerin Jacob wrote: > > On Fri, Jun 16, 2023 at 1:17=E2=80=AFPM Mattias R=C3=B6nnblom > > wrote: > >> > > > > 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. > > The API design is based on community feedback, which suggested more > flexibility was required than the initial > "dispatching-based-on-queue-id-only" functionality the first RFC provided= . > > Where I expected to land was a design where I would have something like > the RFC v2 design with match+process callbacks, and then a supplementary > "hard-coded" dispatch-internal match API as well, where only the process > function would be used (much like how RFC v1 worked). > > It turned out the special-case API was not performing better (rather the > opposite) for the evaluated use cases, so I dropped that idea. > > That said, it could always be a future extension to re-introduce > dispatcher-internal matching. Ack. > > > 2) Need to enforce service core for its usage. > > > > Well, Eventdev does that already, except on systems where all required > event adapters have the appropriate INTERNAL_PORT capability. Yes. The difference is, one is for HW feature emulation and other one for framework 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. > > > > I'm fine with keeping this as a separate library, although I also don't > see the harm in having some utility-type functionality in eventdev itself= . I see harm as 1)It is kind of enforcing above scheme for all the application modeling, which may not applicable for all 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. I would to keep eventDEV library scope as abstracting event device features= . We have some common code in library whose scope is sharing between PMDs not a framework on top eventdev public APIs. Having said that, I supportive to get this framework as new library and happy to review the new library. > > > 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-ste= phen@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 framewo= rk. > > > > > > Thoughts? > > I'm not sure I follow. Are you suggesting rte_graph could use > rte_event_dispatcher, or that an application could use rte_graph to > solve the same problem as rte_event_dispatcher solves? Later one, Application could use rte_graph to solve the same problem as rte_event_dispatcher solves. In fact, both are solving similar problems. See below. > > I didn't review rte_graph in detail, but if it's anything like fd.io > VPP's graph model, it's not a programming model that you switch to > without significant application code impact. This is a new library, right? So, which existing applications? It is not strictly like VPP graph model. rte_graph supports plugin for the different graph models. Following are the models available. https://doc.dpdk.org/guides/prog_guide/graph_lib.html See 62.4.5.1. RTC (Run-To-Completion) 62.4.5.2. Dispatch model RTC is similar to fd.io VPP. Other model is not like VPP. If we choose to take new library route instead of new rte_graph model for eventdev then https://doc.dpdk.org/guides/contributing/new_library.html will be the proce= ss.