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 A482EA0548; Sun, 31 Oct 2021 22:55:31 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 14D7E4068E; Sun, 31 Oct 2021 22:55:31 +0100 (CET) Received: from new3-smtp.messagingengine.com (new3-smtp.messagingengine.com [66.111.4.229]) by mails.dpdk.org (Postfix) with ESMTP id 8CFA640689 for ; Sun, 31 Oct 2021 22:55:29 +0100 (CET) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailnew.nyi.internal (Postfix) with ESMTP id A9D805807D2; Sun, 31 Oct 2021 17:55:27 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Sun, 31 Oct 2021 17:55:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=fm2; bh= pSKX4AyqIzuv92jhtJiWAJ1DHXYacJtp90NffW9Z5Yc=; b=L1bM+anRvRW9xt4I MUjUobXJInImi1jO1HLFnXWTpO4shoomXMRIprxszR+UXz5feC33LA3ZDkTukMud oLVC1NBkdmQKvfmXnfHFtc1YqRV3klHH0gj9BZ7ijKrQ0EEV8ExFO7pe+47Q+4nJ W/VuZzJ82Hvver3WqpWl6v34GN18K0IhA77fViWnphSEnoKn+/eFNRpik1W+wM+i +hmwvRlY1ANyCtZWNouCmjdtRNQAD5Tq6a6fMzLg4xWUFkxDR/Dfx4KA1ER8sMKp Zz7QX79J5oovm02jTvqqTAemPlENY5hFv1w85/I2ZR4IxJKBClhtu9WGjUNV4D/h 9LBUbA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=pSKX4AyqIzuv92jhtJiWAJ1DHXYacJtp90NffW9Z5 Yc=; b=jt+yi9O28m9YoBmFbfI8dRZN40XZDdODpNw0wIymx8HFLDtXLBV9BOALj ++hA02ULu88L6dSkgQZdarNbsfl3a14mwBK1QBkWxACAMYltRv3LVtzCxU93f+HX sca8h5DHZiHq+OnAcTX//Q8uuG1vs5NvSVV2FdSP/aMzz+euWMk/oQ08AJyU2nIr nFcnlxfOr/Q9vURBsAiqXR4W91juK23l2xH6qDHx20CR4LBYsP4v4O/TyEo+I+in 6aZCpFnIVY5HzdfcQGXFpeyjJE2/woesgPj3WsuKQwFduegKr3/J/Gcx+qiFY0Mt bet1vNIb6aTBPFr/iBJeAOmOgbEmQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrvdehtddgudehudcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc ggtffrrghtthgvrhhnpedugefgvdefudfftdefgeelgffhueekgfffhfeujedtteeutdej ueeiiedvffegheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun, 31 Oct 2021 17:55:12 -0400 (EDT) From: Thomas Monjalon To: Jerin Jacob Cc: Mattias =?ISO-8859-1?Q?R=F6nnblom?= , "jerinj@marvell.com" , "dev@dpdk.org" , "ferruh.yigit@intel.com" , "ajit.khaparde@broadcom.com" , "aboyer@pensando.io" , "andrew.rybchenko@oktetlabs.ru" , "beilei.xing@intel.com" , "bruce.richardson@intel.com" , "chas3@att.com" , "chenbo.xia@intel.com" , "ciara.loftus@intel.com" , "dsinghrawat@marvell.com" , "ed.czeck@atomicrules.com" , "evgenys@amazon.com" , "grive@u256.net" , "g.singh@nxp.com" , "zhouguoyang@huawei.com" , "haiyue.wang@intel.com" , "hkalra@marvell.com" , "heinrich.kuhn@corigine.com" , "hemant.agrawal@nxp.com" , "hyonkim@cisco.com" , "igorch@amazon.com" , "irusskikh@marvell.com" , "jgrajcia@cisco.com" , "jasvinder.singh@intel.com" , "jianwang@trustnetic.com" , "jiawenwu@trustnetic.com" , "jingjing.wu@intel.com" , "johndale@cisco.com" , "john.miller@atomicrules.com" , "linville@tuxdriver.com" , "keith.wiles@intel.com" , "kirankumark@marvell.com" , "oulijun@huawei.com" , "lironh@marvell.com" , "longli@microsoft.com" , "mw@semihalf.com" , "spinler@cesnet.cz" , "matan@nvidia.com" , "matt.peters@windriver.com" , "maxime.coquelin@redhat.com" , "mk@semihalf.com" , "humin29@huawei.com" , "pnalla@marvell.com" , "ndabilpuram@marvell.com" , "qiming.yang@intel.com" , "qi.z.zhang@intel.com" , "radhac@marvell.com" , "rahul.lakkireddy@chelsio.com" , "rmody@marvell.com" , "rosen.xu@intel.com" , "sachin.saxena@oss.nxp.com" , "skoteshwar@marvell.com" , "shshaikh@marvell.com" , "shaibran@amazon.com" , "shepard.siegel@atomicrules.com" , "asomalap@amd.com" , "somnath.kotur@broadcom.com" , "sthemmin@microsoft.com" , "steven.webster@windriver.com" , "skori@marvell.com" , "mtetsuyah@gmail.com" , "vburru@marvell.com" , "viacheslavo@nvidia.com" , "xiao.w.wang@intel.com" , "cloud.wangxiaoyun@huawei.com" , "yisen.zhuang@huawei.com" , "yongwang@vmware.com" , "xuanziyang2@huawei.com" , "pkapoor@marvell.com" , "nadavh@marvell.com" , "sburla@marvell.com" , "pathreya@marvell.com" , "gakhil@marvell.com" , "mdr@ashroe.eu" , "dmitry.kozliuk@gmail.com" , "anatoly.burakov@intel.com" , "cristian.dumitrescu@intel.com" , "honnappa.nagarahalli@arm.com" , "ruifeng.wang@arm.com" , "drc@linux.vnet.ibm.com" , "konstantin.ananyev@intel.com" , "olivier.matz@6wind.com" , "jay.jayatheerthan@intel.com" , "asekhar@marvell.com" , "pbhagavatula@marvell.com" , Elana Agostini Date: Sun, 31 Oct 2021 22:55:10 +0100 Message-ID: <6391601.jCN5kLYsqS@thomas> In-Reply-To: References: <20211019181459.1709976-1-jerinj@marvell.com> <15147533.nJ1qs5LPEr@thomas> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [RFC PATCH 0/1] Dataplane Workload Accelerator library 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 Sender: "dev" 31/10/2021 22:13, Jerin Jacob: > On Mon, Nov 1, 2021 at 1:04 AM Thomas Monjalon wrote: > > > > 31/10/2021 15:01, Jerin Jacob: > > > Since rte_flow already has the TLV concept it may not be new to DPDK. > > > > Where is there TLV in rte_flow? > > struct rte_flow_item { > enum rte_flow_item_type type; /**< Item type. */ > const void *spec; /**< Pointer to item specification structure. */ > > Type is the tag here and the spec is the value here. Length is the > size of the specification structure. > rte_flows spec does not support/need zero length variable at the end > of spec structure, > that reason for not embedding explicit length value as it is can be > derived from sizeof(specification structure). Ah OK I see what you mean. But rte_flow_item is quite limited, it is not the kind of TLV with multiple levels of nesting. Do you need nesting of objects in DWA? > > > I really liked rte_flow enablement of ABI combability and its ease of adding > > > new stuff. Try to follow similar stuff which is proven in DPDK. > > > Ie. New profile creation will very easy, it will be a matter of identifying > > > the TLVs and their type and payload, rather than everyone comes with > > > new APIs in every profile. > > > > > > > Why not use protobuf and its IDL to specify the interface? > > > > Yes I think it is important to discuss alternatives, > > and at least get justifications of why TLV is chosen among others. > > Yes. Current list is > > 1) Very easy to enable ABI compatibility. > 2) If it needs to be transported over network etc it needs to be > packed so that way it is easy for implementation to do that > with TLV also gives better performance in such > cases by avoiding reformatting or possibly avoiding memcpy etc. > 3) It is easy to plugin with another high-level programing language as > just one API. > 4) Easy to decouple DWA core library functionalities from profile. > 5) Easy to enable asynchronous scheme using request and response TLVs. > 6) Most importantly, We could introduce type notion with TLV > (connected with the type of message See TYPE_ATTACHED, TYPE_STOPPED, > TYPE_USER_PLANE etc ), > That way, we can have a uniform outlook of profiles instead of each profile > coming with a setup of its own APIs and __rules__ on the state machine. > I think, for a framework to leverage communication mechanisms and other > aspects between profiles, it's important to have some synergy between profiles. > 7) No Additional library dependencies like gRPC, protobuf > 8) Provide driver to implement the optimized means of supporting different > transport such as Ethernet, Shared memory, PCIe DMA style HW etc. > 9) Avoid creating endless APIs and their associated driver function > calls for each > profile APIs.