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 B98F142604; Thu, 21 Sep 2023 09:24:09 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 552EE4026D; Thu, 21 Sep 2023 09:24:09 +0200 (CEST) Received: from mail-vs1-f52.google.com (mail-vs1-f52.google.com [209.85.217.52]) by mails.dpdk.org (Postfix) with ESMTP id B4E934014F; Thu, 21 Sep 2023 09:24:07 +0200 (CEST) Received: by mail-vs1-f52.google.com with SMTP id ada2fe7eead31-45269fe9d6bso350842137.2; Thu, 21 Sep 2023 00:24:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1695281047; x=1695885847; darn=dpdk.org; 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=rXXsEJqIKeIc0R+zAaAgSpnQh/MxHXRa/UhG7pgjPsA=; b=nfsiZfWHpo7VWelxuqGMg6wzy7/+cjTMchIiEjXRt8aJy7Kqoy32Z9S+16cp02QTcd 06elO1RoHubjiWEQzTi5eHd9gYk+6oIY5EDCPbRc83ZnuNPVY6yJ1sRc8+f8lMEN65FQ 0GprD53jC2xXQ61r45b9IExLu4fNNE7WDs8lsv84x5n4tr/PIrQzeuuiLKnnfg4/xeTi 1yohLspkB9+on+xOpmfmmHZt+TlwKmB1BNd6ET4DrfNgxnLObELdMAHJgaWQ1ZnM0XEs x22AHFxj3cJfcJvwHfewIfBsv0k5PFr/hNwrdQQRF6cGuZn+Nh4otSH5R9sA3r1jLmF/ h7gw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695281047; x=1695885847; 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=rXXsEJqIKeIc0R+zAaAgSpnQh/MxHXRa/UhG7pgjPsA=; b=uw7b7s8lrmwXOfXNqRuOr0nCv8HfPcIsTPusyuIXlYY9YZ6hdMvy8EueTNrSbnq5V0 vXcNY8IwqI6Awhl8uUfN65mVnD5FRXI4C0FMWuGYSPMCJw9nUsk6wPiq2oFyM9tFAjmy UfdPTd1LqRNmrljIMhy6ln5bew/8qGttWvv6BPWSGjEV9Px0xI6UO3XW+luf6+7NPJqC IU5ki5iyAxcyPvDYoO9dUunDomB9hRl0ZV4fw4eO8KNindtodG7ySaYL75xtQ4DdAPGE FnFrktgulRVLMEsASf4dkRbLJLYID4TglKmMM3wD78rASSweEylbepUDUQN9+F23CRqi vlSQ== X-Gm-Message-State: AOJu0Ywq7xSaIdCfIMGUd7VeWRqJmDkl3K7l6LA3C7VeqPYaGNIMltZv Rc3oCfW+VG81+yTmxhoFMcNVZZeRvmllFPnMM+U= X-Google-Smtp-Source: AGHT+IEuh2MTloYFzuTNIAYxm2Va98Zy01clNrsfFjR7CGarrRSlo7/7M9KJV79LPj1YYbZ2B83zc+YmhKhGt8Lo3bk= X-Received: by 2002:a67:eb59:0:b0:447:6bdc:654c with SMTP id x25-20020a67eb59000000b004476bdc654cmr5155168vso.31.1695281047009; Thu, 21 Sep 2023 00:24:07 -0700 (PDT) MIME-Version: 1.0 References: <20230616074041.159675-2-mattias.ronnblom@ericsson.com> <20230904130313.327809-1-mattias.ronnblom@ericsson.com> <20230904130313.327809-2-mattias.ronnblom@ericsson.com> In-Reply-To: From: Jerin Jacob Date: Thu, 21 Sep 2023 12:53:40 +0530 Message-ID: Subject: Re: [PATCH v3 1/3] lib: introduce dispatcher library To: "Naga Harish K, S V" Cc: "mattias.ronnblom" , "dev@dpdk.org" , Jerin Jacob , "techboard@dpdk.org" , "Van Haaren, Harry" , "hofors@lysator.liu.se" , "Nilsson, Peter" , Heng Wang , Pavan Nikhilesh , "Gujjar, Abhinandan S" , "Carrillo, Erik G" , Shijith Thotton , Hemant Agrawal , Sachin Saxena , Liang Ma , "Mccarthy, Peter" , "Yan, Zhirun" 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, Sep 21, 2023 at 11:29=E2=80=AFAM Naga Harish K, S V wrote: > > > > > -----Original Message----- > > From: Jerin Jacob > > Sent: Wednesday, September 20, 2023 3:02 PM > > To: Naga Harish K, S V > > Cc: mattias.ronnblom ; dev@dpdk.org; > > Jerin Jacob ; techboard@dpdk.org; Van Haaren, Harry > > ; hofors@lysator.liu.se; Nilsson, Peter > > ; Heng Wang ; > > Pavan Nikhilesh ; Gujjar, Abhinandan S > > ; Carrillo, Erik G ; > > Shijith Thotton ; Hemant Agrawal > > ; Sachin Saxena ; > > Liang Ma ; Mccarthy, Peter > > ; Yan, Zhirun > > Subject: Re: [PATCH v3 1/3] lib: introduce dispatcher library > > > > On Mon, Sep 18, 2023 at 5:26=E2=80=AFAM Naga Harish K, S V > > wrote: > > > > > > > > > > > > > -----Original Message----- > > > > From: Mattias R=C3=B6nnblom > > > > Sent: Monday, September 4, 2023 6:33 PM > > > > To: dev@dpdk.org > > > > Cc: Jerin Jacob ; techboard@dpdk.org; Van > > > > Haaren, Harry ; hofors@lysator.liu.se; > > > > Nilsson, Peter ; Heng Wang > > > > ; Naga Harish K, S V > > > > ; Pavan Nikhilesh > > > > ; Gujjar, Abhinandan S > > > > ; Carrillo, Erik G > > > > ; Shijith Thotton = ; > > > > Hemant Agrawal ; Sachin Saxena > > > > ; Liang Ma ; > > > > Mccarthy, Peter ; Yan, Zhirun > > > > ; mattias.ronnblom > > > > > > > > Subject: [PATCH v3 1/3] lib: introduce dispatcher library > > > > > > > > The purpose of the dispatcher library is to help reduce coupling in > > > > an Eventdev-based DPDK application. > > > > > > > > In addition, the 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 > > > > > > > > -- > > > > > > > > PATCH v3: > > > > o To underline its optional character and since it does not provid= e > > > > hardware abstraction, the event dispatcher is now a separate > > > > library. > > > > o Change name from rte_event_dispatcher -> rte_dispatcher, to make= it > > > > shorter and to avoid the rte_event_* namespace. > > > > > > > > > > Rte_dispatcher is basically dispatching events but it feels like the = name does > > not convey that. > > > Also, it is like any other adapter service that can reside within the= eventdev > > directory. > > > > > > I can see some discussion in previous threads related to the placemen= t of the > > dispatcher library. > > > > > > It is an optional eventdev application service, not enforcing this > > programming model to the application. > > > The documentation may need to be updated and mention that this is > > optional. > > > > > > If any hardware comes up with the dispatcher feature, then this libra= ry may > > need to be moved inside eventdev library later. > > > > I would like to follow YAGNI principle in eventdev library. > > What is YAGNI principle? for understanding purposes. https://www.techtarget.com/whatis/definition/You-arent-gonna-need-it#:~:tex= t=3DYAGNI%20principle%20(%22You%20Aren',desired%20increased%20frequency%20o= f%20releases. What meant by that, If it meant to be abstracting any HW Device feature(on the point of above: If any hardware comes up with the dispatcher feature, then this library may need to be moved inside eventdev library later) lest define API based on a Device definition and its capability. If it is targeting for an SW library align API based on that. For example, If this needed to be implemented in HW as device feature, I would implement as following - CAM as ACL or EM to store the rules - Key extractor to extract the interested filed(match actions). Similar to rte_flow flow patterns - Action will something similar to rte_flow mark action (https://doc.dpdk.org/guides/prog_guide/rte_flow.html#action-mark). - When packet/event delivered to application. HW stores the mark value in the metadata up on match. For such HW, if we try to abstract with current API proposal, it is not efficient. On the other way, if the use case, addressing the existing SW API library and model around the above HW primitives also not efficient.