From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
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 <dev@dpdk.org>; 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: <xms:zBB_YR0Ixkj1STDPaMXDm-6LIEx8irf-qe3gZbCaoNQkcxLVVu5tYw>
<xme:zBB_YYGeTdCKIpeDoJuvzfP0eW_6rRB9gQ1LRdfKkHNSAdNo_DZsruNro35qQa6ht
ouxdbeF97s8lqfNMw>
X-ME-Received: <xmr:zBB_YR67wGGagGZh7T2F2BhmeXVVsrq1SQCuAS__LZ-HaUcWjeWPuJzxs_LzOwUl_YwnpGxVK-Mva8RMI0aK>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrvdehtddgudehudcutefuodetggdotefrod
ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh
necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd
enucfjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhm
rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc
ggtffrrghtthgvrhhnpedugefgvdefudfftdefgeelgffhueekgfffhfeujedtteeutdej
ueeiiedvffegheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh
hrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght
X-ME-Proxy: <xmx:zBB_Ye0LuI-Kdk8_qutRr2sglSXYZbwqFGMGmzbnlXGGyoh47SlDGA>
<xmx:zBB_YUHG00xNYJnXcZ7-fsD5EmhWC-712XpYOjOVs_khoU6LLd_Fpw>
<xmx:zBB_Yf9rHJ37ZWTVvMvayV_Rco1X6-qhJK8nl9u3-3-FpaRrYTKXpw>
<xmx:zxB_YURhBcHtOq2WH8wJkAIynq4JpsEdLCXdXfOTWZXZwzPPSk3pQg>
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun,
31 Oct 2021 17:55:12 -0400 (EDT)
From: Thomas Monjalon <thomas@monjalon.net>
To: Jerin Jacob <jerinjacobk@gmail.com>
Cc: Mattias =?ISO-8859-1?Q?R=F6nnblom?= <mattias.ronnblom@ericsson.com>,
"jerinj@marvell.com" <jerinj@marvell.com>, "dev@dpdk.org" <dev@dpdk.org>,
"ferruh.yigit@intel.com" <ferruh.yigit@intel.com>,
"ajit.khaparde@broadcom.com" <ajit.khaparde@broadcom.com>,
"aboyer@pensando.io" <aboyer@pensando.io>,
"andrew.rybchenko@oktetlabs.ru" <andrew.rybchenko@oktetlabs.ru>,
"beilei.xing@intel.com" <beilei.xing@intel.com>,
"bruce.richardson@intel.com" <bruce.richardson@intel.com>,
"chas3@att.com" <chas3@att.com>,
"chenbo.xia@intel.com" <chenbo.xia@intel.com>,
"ciara.loftus@intel.com" <ciara.loftus@intel.com>,
"dsinghrawat@marvell.com" <dsinghrawat@marvell.com>,
"ed.czeck@atomicrules.com" <ed.czeck@atomicrules.com>,
"evgenys@amazon.com" <evgenys@amazon.com>,
"grive@u256.net" <grive@u256.net>, "g.singh@nxp.com" <g.singh@nxp.com>,
"zhouguoyang@huawei.com" <zhouguoyang@huawei.com>,
"haiyue.wang@intel.com" <haiyue.wang@intel.com>,
"hkalra@marvell.com" <hkalra@marvell.com>,
"heinrich.kuhn@corigine.com" <heinrich.kuhn@corigine.com>,
"hemant.agrawal@nxp.com" <hemant.agrawal@nxp.com>,
"hyonkim@cisco.com" <hyonkim@cisco.com>,
"igorch@amazon.com" <igorch@amazon.com>,
"irusskikh@marvell.com" <irusskikh@marvell.com>,
"jgrajcia@cisco.com" <jgrajcia@cisco.com>,
"jasvinder.singh@intel.com" <jasvinder.singh@intel.com>,
"jianwang@trustnetic.com" <jianwang@trustnetic.com>,
"jiawenwu@trustnetic.com" <jiawenwu@trustnetic.com>,
"jingjing.wu@intel.com" <jingjing.wu@intel.com>,
"johndale@cisco.com" <johndale@cisco.com>,
"john.miller@atomicrules.com" <john.miller@atomicrules.com>,
"linville@tuxdriver.com" <linville@tuxdriver.com>,
"keith.wiles@intel.com" <keith.wiles@intel.com>,
"kirankumark@marvell.com" <kirankumark@marvell.com>,
"oulijun@huawei.com" <oulijun@huawei.com>,
"lironh@marvell.com" <lironh@marvell.com>,
"longli@microsoft.com" <longli@microsoft.com>,
"mw@semihalf.com" <mw@semihalf.com>,
"spinler@cesnet.cz" <spinler@cesnet.cz>,
"matan@nvidia.com" <matan@nvidia.com>,
"matt.peters@windriver.com" <matt.peters@windriver.com>,
"maxime.coquelin@redhat.com" <maxime.coquelin@redhat.com>,
"mk@semihalf.com" <mk@semihalf.com>,
"humin29@huawei.com" <humin29@huawei.com>,
"pnalla@marvell.com" <pnalla@marvell.com>,
"ndabilpuram@marvell.com" <ndabilpuram@marvell.com>,
"qiming.yang@intel.com" <qiming.yang@intel.com>,
"qi.z.zhang@intel.com" <qi.z.zhang@intel.com>,
"radhac@marvell.com" <radhac@marvell.com>,
"rahul.lakkireddy@chelsio.com" <rahul.lakkireddy@chelsio.com>,
"rmody@marvell.com" <rmody@marvell.com>,
"rosen.xu@intel.com" <rosen.xu@intel.com>,
"sachin.saxena@oss.nxp.com" <sachin.saxena@oss.nxp.com>,
"skoteshwar@marvell.com" <skoteshwar@marvell.com>,
"shshaikh@marvell.com" <shshaikh@marvell.com>,
"shaibran@amazon.com" <shaibran@amazon.com>,
"shepard.siegel@atomicrules.com" <shepard.siegel@atomicrules.com>,
"asomalap@amd.com" <asomalap@amd.com>,
"somnath.kotur@broadcom.com" <somnath.kotur@broadcom.com>,
"sthemmin@microsoft.com" <sthemmin@microsoft.com>,
"steven.webster@windriver.com" <steven.webster@windriver.com>,
"skori@marvell.com" <skori@marvell.com>,
"mtetsuyah@gmail.com" <mtetsuyah@gmail.com>,
"vburru@marvell.com" <vburru@marvell.com>,
"viacheslavo@nvidia.com" <viacheslavo@nvidia.com>,
"xiao.w.wang@intel.com" <xiao.w.wang@intel.com>,
"cloud.wangxiaoyun@huawei.com" <cloud.wangxiaoyun@huawei.com>,
"yisen.zhuang@huawei.com" <yisen.zhuang@huawei.com>,
"yongwang@vmware.com" <yongwang@vmware.com>,
"xuanziyang2@huawei.com" <xuanziyang2@huawei.com>,
"pkapoor@marvell.com" <pkapoor@marvell.com>,
"nadavh@marvell.com" <nadavh@marvell.com>,
"sburla@marvell.com" <sburla@marvell.com>,
"pathreya@marvell.com" <pathreya@marvell.com>,
"gakhil@marvell.com" <gakhil@marvell.com>, "mdr@ashroe.eu" <mdr@ashroe.eu>,
"dmitry.kozliuk@gmail.com" <dmitry.kozliuk@gmail.com>,
"anatoly.burakov@intel.com" <anatoly.burakov@intel.com>,
"cristian.dumitrescu@intel.com" <cristian.dumitrescu@intel.com>,
"honnappa.nagarahalli@arm.com" <honnappa.nagarahalli@arm.com>,
"ruifeng.wang@arm.com" <ruifeng.wang@arm.com>,
"drc@linux.vnet.ibm.com" <drc@linux.vnet.ibm.com>,
"konstantin.ananyev@intel.com" <konstantin.ananyev@intel.com>,
"olivier.matz@6wind.com" <olivier.matz@6wind.com>,
"jay.jayatheerthan@intel.com" <jay.jayatheerthan@intel.com>,
"asekhar@marvell.com" <asekhar@marvell.com>,
"pbhagavatula@marvell.com" <pbhagavatula@marvell.com>,
Elana Agostini <eagostini@nvidia.com>
Date: Sun, 31 Oct 2021 22:55:10 +0100
Message-ID: <6391601.jCN5kLYsqS@thomas>
In-Reply-To: <CALBAE1Od6-iqEYnDCGRJSS8efxwNZxO7GMUm2hsdoC0ApKVJRg@mail.gmail.com>
References: <20211019181459.1709976-1-jerinj@marvell.com>
<15147533.nJ1qs5LPEr@thomas>
<CALBAE1Od6-iqEYnDCGRJSS8efxwNZxO7GMUm2hsdoC0ApKVJRg@mail.gmail.com>
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 <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>
31/10/2021 22:13, Jerin Jacob:
> On Mon, Nov 1, 2021 at 1:04 AM Thomas Monjalon <thomas@monjalon.net> 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.