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 54AFEA0548; Sun, 31 Oct 2021 22:13:47 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id D38474068E; Sun, 31 Oct 2021 22:13:46 +0100 (CET) Received: from mail-il1-f170.google.com (mail-il1-f170.google.com [209.85.166.170]) by mails.dpdk.org (Postfix) with ESMTP id E1DE740689 for ; Sun, 31 Oct 2021 22:13:44 +0100 (CET) Received: by mail-il1-f170.google.com with SMTP id f10so12007645ilu.5 for ; Sun, 31 Oct 2021 14:13:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bMXZXeIJ0OngmzpoHgPLCR22liOdTYfdcSOM0dMZpnE=; b=jY8I4RYlt7gobOcA05rWq3/mh4AQ8/AH8fwV9Pyn4QLnaiGvFveNiV/5b8q4QVW71U lAw2usv+Jg/kCmJGoF+rBZxnl7BdTHb8hk6ZzC9Kk2/DfwjXTfzFzmXZN0DP4Mf/7rPQ LsSqOMoSQHGyUTKWn6CUBtE6t08jMYRpty5e33iiHHZ2yr13N8gX7HOz+EiPKcS2TyAy yhrytJ7hs7WHfeaR7FAl5UyTZ0WNplc+FrsK7IKuDABeTolplfJXHmBBIbbVsmuLa+G7 cAjwaMjHwCT3eYsO2UPCS/+pcWRJwJs+AS5LTvsxGCzGg36QqcLPY7sNgF0yLfqilZWU EacQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=bMXZXeIJ0OngmzpoHgPLCR22liOdTYfdcSOM0dMZpnE=; b=8MqgGJUql/00peKwXSzInTfFXG/tFRd4TEQnQlhSuJ3jtKkqEpCrrnqoOzTLrUiKNV zgOz2cEeRrvn5C6h077h+sCKcZtNacMOkp4PoRzfDzhRFxCdkhctPu64bWMrIDmxyX8h cpazerzjGuXEaOxKEX5kBDwyyJezlnbHz3KqK58eR96THRf/lZxFQTwhu6fvi0tngP1m LLwsfkpCWW2b1iEdjFnmi54hMB2NSLnJzSd0uWRPxuSosYKrXH1GYAnR9LLX52jjy4J7 rApJA0bhKK9Jxi7tFnRq6pbIrmZEVeIBHnRkGNjNHX3vINMayWJVLkWX+QtvnTkGsQ7q c0YQ== X-Gm-Message-State: AOAM5316VZI76cNgsy0n2Ofxhru8/eddpWiLquNDZvu+H+08R2UUk5gn 2tl/q46hrDRJnNepRfGvel9MxJ2Y/6iD++CRxf0= X-Google-Smtp-Source: ABdhPJyttMqyorq6CXrIdpAJMlURQO/kGBMC502bo4iccbZ3Hfap3xEjpFrMU1DumKK858IZfRysidCwkHFR+9lgFBo= X-Received: by 2002:a05:6e02:174d:: with SMTP id y13mr17059144ill.251.1635714824190; Sun, 31 Oct 2021 14:13:44 -0700 (PDT) MIME-Version: 1.0 References: <20211019181459.1709976-1-jerinj@marvell.com> <15147533.nJ1qs5LPEr@thomas> In-Reply-To: <15147533.nJ1qs5LPEr@thomas> From: Jerin Jacob Date: Mon, 1 Nov 2021 02:43:18 +0530 Message-ID: To: Thomas Monjalon Cc: =?UTF-8?Q?Mattias_R=C3=B6nnblom?= , "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 Content-Type: text/plain; charset="UTF-8" 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" 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). > > > 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. > >