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 24F81430E2; Fri, 25 Aug 2023 09:28:01 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 0526040A7A; Fri, 25 Aug 2023 09:28:01 +0200 (CEST) Received: from mail-vk1-f175.google.com (mail-vk1-f175.google.com [209.85.221.175]) by mails.dpdk.org (Postfix) with ESMTP id F306740695; Fri, 25 Aug 2023 09:27:59 +0200 (CEST) Received: by mail-vk1-f175.google.com with SMTP id 71dfb90a1353d-48d14d11756so254183e0c.2; Fri, 25 Aug 2023 00:27:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1692948479; x=1693553279; 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=NNi7vLpWpdkqGLauOrMhZliYBF98ZvCdFcWVZ/6TUVA=; b=c9EzIi1AgLnAD8fy3Nwi4wduSzR8avy6JXEiBz7vzv6RpXF1osyaoviXK6BqwgD3P8 4rA8yhjFJGPZZc+nUmc+TtKivac2M/pXbTBngr8YhOr31PxG0ZjYcSJ5EZrCs5YLR7fM zLbQMeiGmgrxlDzJyO0W8I5o4pGVDAGtY57eduSROiJYdfOaQOqtDmAhb/D/FS2Kj0o3 E6D9afl5SsM9D+KO9bu8mnMLxqGrIA0b4NKrZJLLxVReHwsH56Fl2DGdLZL2pwWgXWvY WTV0iCm0rl/HXy0JrAeICXkUX+BwGYv7F5ALuV61K22ogbcGgXp7HSO8UmYCH1YH91uH YC0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1692948479; x=1693553279; 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=NNi7vLpWpdkqGLauOrMhZliYBF98ZvCdFcWVZ/6TUVA=; b=X5ulqjotMvbUvlKYLA0fFcnX+5k6R3v4EGH1k/0hRMofDA7npONQiOuGbu+zDaebCQ YzwQ0CAM3uK55yUzeccWF3pvAo8L+LJW7oXFSuPAWud2xU63DfDttajo6+x3snexonJh T4JbhpyIpQB2VHJCm8pGOns5q6aIWVwAvx+E+Hv3lVzvK3eBnPTt6MhneR0Vh2wzL0WL QAlAuVG5cdt8VgPhI0aEsCVuVU3DFSlrYW1IhaP9OZz92EuzMt+CbWmV5YER5FRRNpdI 0zEeEg4dhepxd3+3OO23b6+BcsGCMMPx2GuzRX3O3AF48j28TyjYxrET4QmeE4/IktrP //4g== X-Gm-Message-State: AOJu0Yxxf6crX0OymmL6QqvtxNQXWkFZMxMRM3jwL0POQ2nmktfLa4zF 4ylmMbt4I2+Nby68NF1nbWRrIzOg+me/pHT3+NM= X-Google-Smtp-Source: AGHT+IH2z4wAQqEqR9sjmYAuaW1mcKD2gR1XZPeI9PbKML3DodpHoVgE9YuFbJZrMZyqaflsmqFfwYTYkT28rw7J/4s= X-Received: by 2002:a1f:c843:0:b0:48c:f9e9:51a8 with SMTP id y64-20020a1fc843000000b0048cf9e951a8mr17088866vkf.9.1692948479181; Fri, 25 Aug 2023 00:27:59 -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> <644934bc-a10f-5db6-cf0f-819c3828fdf6@lysator.liu.se> In-Reply-To: <644934bc-a10f-5db6-cf0f-819c3828fdf6@lysator.liu.se> From: Jerin Jacob Date: Fri, 25 Aug 2023 12:57:33 +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 Thu, Aug 24, 2023 at 4:47=E2=80=AFPM Mattias R=C3=B6nnblom wrote: > > On 2023-08-22 14:32, Jerin Jacob wrote: > >> 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. > > > > Can you elaborate why that difference is relevant? > > Both the adapters and the event dispatcher are optional, so if you have > an issue with service cores, you can avoid their use. Adaptor's service core is not optional if HW don't have that feature via adaptor API. > > > > 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. > > > > What scheme is being enforced? Using this thing is optional. Yes. Exposing in rte_event_.... name space and framework is in lib/eventdev= , one can think, it is layerd SW model and top most event dispatch needs to be used. Changing the namespace and move to different library will fix that problem. > > > 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 feat= ures. > > 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. > > > > Thanks. > > I'll reshape the event dispatcher as a separate library and submit a new > patch. Ack > >> > >> 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? > > > > Existing DPDK applications, which domain logic is not organized as a > graph. Which, I'm guessing, are many. Yes. But I was comparing new application based on Graph vs new event dispatch model, not Graph vs "raw" event device. Nevertheless, if there are some in house application which is following event dispatch model and one wants to make that model as upstream as new library. No objections from my side. > > Moving from "raw" event device dequeue to the event dispatcher model is > a trivial, non-intrusive, operation. > > > 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 p= rocess.