From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <dev-bounces@dpdk.org> Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 3DECAA05A0; Tue, 21 Apr 2020 23:51:48 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id AEB481D181; Tue, 21 Apr 2020 23:51:47 +0200 (CEST) Received: from new4-smtp.messagingengine.com (new4-smtp.messagingengine.com [66.111.4.230]) by dpdk.org (Postfix) with ESMTP id D50061D17F for <dev@dpdk.org>; Tue, 21 Apr 2020 23:51:45 +0200 (CEST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailnew.nyi.internal (Postfix) with ESMTP id 6EBE55802D8; Tue, 21 Apr 2020 17:51:45 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Tue, 21 Apr 2020 17:51:45 -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=fm1; bh= VZugGjOKU9GXgHEZ7g8wdAdriqSycFN47sGTMT8quZQ=; b=u8Ixv2P73iZGgZy9 IaIGBOAmuFHdaNoTzT5ksbOOP5geUIQXNqsnfb51BgFIBQgLZLJXO/4tyX+KzdV2 lAz8kMSYFkUUPFsV3WgyeQknockiEi4GHqy3Gsd8e/LO5EOmvkW66ssBvvPuxkWN wmgC7O1xQPcgIfj3995Xa5qDlgwlVFnPXYRU69hbWOGMQmQP8k/3vFQSwdqkFQVr BThGbBPOPfPZc3E4xDp2iNAMjTGatxgjopB4TLdg3+BwufkAe0xcluKqrHPey6E7 eEJBcjQG3ODiaDkgPScTUCCy77VIU3uZqbecd0nXDATlMRS8cph638dqS7t4T3Vt Qu8HVQ== 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=fm2; bh=VZugGjOKU9GXgHEZ7g8wdAdriqSycFN47sGTMT8qu ZQ=; b=verBBw7NXRl60UZFKkuFoVcW8fPD2qys+C/0wUAaM/UBrOYqKkAwMx4ir dU167N3TYcVUb6jATxYJD5OTof94KMPwJ4fnua6lO71yUndBdduxFjU0NP5HHd7m j+BkJqruvUDnNQ4jvGDzg51IXFQxOlGrBoxTeI3ZaDjV6s/xb0gDRG/SKYps8QkL dz0cxzbP/V69M5e7MbsBHQ+wG2fuSpKkp/yYIyUnq0yIrQwMz++Qu3/a3JefR7Ub A3NJHi1HlAPgGJNt+Fsqli0g07fIzhiJ1vpWiqn9QatyllEqVcceKl4MQDghoDlu +rj/rYABRQaOTpq79vBu9SUwH1LDw== X-ME-Sender: <xms:72qfXpRUohnOyTOSqhVpd-HvT0YnJviqS5gyQLIJQzOZP7l8yPZCSA> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrgeeigddtvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghs ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucffoh hmrghinhepughpughkrdhorhhgpdhouhhtlhhoohhkrdgtohhmnecukfhppeejjedrudef gedrvddtfedrudekgeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrih hlfhhrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght X-ME-Proxy: <xmx:72qfXoyaHuvWwC8jJuGU0Kjn6LRV63ZlHT0g8To0TGgPcZjf1_JlPg> <xmx:72qfXseLOrBWLfGMvKNJ-Uq1fWLprb35Wu3nMq9RxuyMt4XVnDN8_Q> <xmx:72qfXsKW0DdwvaWjknLy9EeILsrnrq51ADOmfEK8QffxEu2XZlA91A> <xmx:8WqfXk0aCR9MkRPnWT1wtdRyVTsDnHHo_neb8k0fuwuSosm2YhKZag> Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 4A7BC3065C9A; Tue, 21 Apr 2020 17:51:40 -0400 (EDT) From: Thomas Monjalon <thomas@monjalon.net> To: "Doherty, Declan" <declan.doherty@intel.com>, "Coyle, David" <david.coyle@intel.com> Cc: "Yigit, Ferruh" <ferruh.yigit@intel.com>, "Trahe, Fiona" <fiona.trahe@intel.com>, "dev@dpdk.org" <dev@dpdk.org>, "De Lara Guarch, Pablo" <pablo.de.lara.guarch@intel.com>, "Ryan, Brendan" <brendan.ryan@intel.com>, "shreyansh.jain@nxp.com" <shreyansh.jain@nxp.com>, "hemant.agrawal@nxp.com" <hemant.agrawal@nxp.com>, "akhil.goyal@nxp.com" <akhil.goyal@nxp.com>, Anoob Joseph <anoobj@marvell.com>, Ruifeng Wang <ruifeng.wang@arm.com>, Liron Himi <lironh@marvell.com>, Nagadheeraj Rottela <rnagadheeraj@marvell.com>, Srikanth Jampala <jsrikanth@marvell.com>, Gagandeep Singh <g.singh@nxp.com>, Jay Zhou <jianjay.zhou@huawei.com>, Ravi Kumar <ravi1.kumar@amd.com>, "Richardson, Bruce" <bruce.richardson@intel.com>, "olivier.matz@6wind.com" <olivier.matz@6wind.com>, "honnappa.nagarahalli@arm.com" <honnappa.nagarahalli@arm.com>, Stephen Hemminger <stephen@networkplumber.org>, "alexr@mellanox.com" <alexr@mellanox.com>, "jerinj@marvell.com" <jerinj@marvell.com>, Pavan Nikhilesh <pbhagavatula@marvell.com> Date: Tue, 21 Apr 2020 23:51:39 +0200 Message-ID: <1849198.8hb0ThOEGa@thomas> In-Reply-To: <MN2PR11MB35502DABCD696D9AD33F69CBE3D50@MN2PR11MB3550.namprd11.prod.outlook.com> References: <20200410142757.31508-1-david.coyle@intel.com> <1617700.QkHrqEjB74@thomas> <MN2PR11MB35502DABCD696D9AD33F69CBE3D50@MN2PR11MB3550.namprd11.prod.outlook.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v3 0/4] add AESNI-MB rawdev for multi-function processing X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 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> 21/04/2020 20:37, Coyle, David: > From: Thomas Monjalon <thomas@monjalon.net> > > 21/04/2020 18:46, Doherty, Declan: > > > On 15/04/2020 11:33 PM, Thomas Monjalon wrote: > > > > 16/04/2020 00:19, Doherty, Declan: > > > >> On 14/04/2020 3:44 PM, Thomas Monjalon wrote: > > > >>> 14/04/2020 16:02, Trahe, Fiona: > > > >>>> From: Thomas Monjalon <thomas@monjalon.net> > > > >>>>> 14/04/2020 15:04, Trahe, Fiona: > > > >>>>>>> 14/04/2020 12:21, Ferruh Yigit: > > > >>>>>>> > > > >>>>> > > http://inbox.dpdk.org/dev/MN2PR11MB35507D4B96677A41E66440C5E3C30 > > > >>>>> @MN2PR11MB3550.na > > > >>>>>>> mprd11.prod.outlook.com/ > > > >>>>>>> > > > >>>>>>> I am not convinced. > > > >>>>>>> I don't like rawdev in general. > > > >>>>>>> Rawdev is good only for hardware support which cannot be > > > >>>>>>> generic like SoC, FPGA management or DMA engine. > > > >>>>>> > > > >>>>>> [Fiona] CRC and BIP are not crypto algorithms, they are error > > detection processes. > > > >>>>>> So there is no class in DPDK that these readily fit into. > > > >>>>>> There was resistance to adding another xxxddev, and even if one > > > >>>>>> had been added for error_detection_dev, there would still have > > > >>>>>> been another layer needed to couple this with cryptodev. > > > >>>>>> Various proposals for this have been discussed on the ML in RFC > > and recent patches, there doesn't seem to be an appetite for this as a > > generic API. > > > >>>>>> So it seems that only Intel has software and hardware engines > > > >>>>>> that provide this specialised feature coupling. In that case > > > >>>>>> rawdev seems like the most appropriate vehicle to expose this. > > > >>>>> > > > >>>>> Adding some vendor-specific API is not a good answer. > > > >>>>> It will work in some cases, but it won't make DPDK better. > > > >>>>> What's the purpose of DPDK if it's not solving a common problem > > > >>>>> for different hardware? > > > >>>> > > > >> The current proposal in rawdev could easily be supported by any > > > >> hardware which supports chaining multiple functions/services into a > > > >> single operation, in this case symmetric crypto and error > > > >> detection, but it could conceivably support chaining > > > >> symmetric/asymmetric crypto operations or chaining symmetric crypto > > and compression operations. > > > >> > > > >>>> [Fiona] Based on that logic rawdev should be deprecated. > > > >>>> But the community has agreed that it has a place. > > > >>> > > > >>> No, as I said above, rawdev is good for SoC, FPGA management or > > DMA engine. > > > >> > > > >> I distinctly remember when rawdev was being proposed one of the > > > >> uses cases proposed was that a new classes of APIs could be > > > >> prototyped and developed under rawdev and when a solid consensus > > > >> was reached then migrated to a mainstream DPDK library. I think > > > >> every effort has been made here to engage the community to develop > > > >> a generic approach. As Fiona notes there hasn't really been much of an > > appetite for this. > > > >> > > > >> Therefore I think the option to use rawdev makes sense, it allows > > > >> an initial proposal to be deployed, without a generic solution > > > >> agreement, it will also give others in the community to see how > > > >> this approach can work and hopefully lead to more engagement on a > > > >> generic solution. Also as APIs in rawdev are essentially treated as > > > >> private APIs the onus is on Intel to support this going forward. > > > > > > > > Because hardware support is pending, we should accept an Intel-only > > > > "temporary" solution, opening the door to more vendor-specific APIs? > > > > > > > > What is the benefit for the DPDK project? > > > > > > Sorry I don't agree with this sentiment, David has made every attempt > > > to solicit feedback an to engage the community in this. > > > > Really? > > > > These are the recipients of the first patch: > > dev@dpdk.org, declan.doherty@intel.com, fiona.trahe@intel.com In > > next patches, only Intel and NXP are Cc'ed. > > Stephen and Jerin, who gave good comments on first patch, were not Cc'ed > > in next versions. > > > > Was it presented in an event? > > Was it brought to the techboard? > > Please don't exagerate and admit you are trying to push something which is > > specific and convenient for Intel QuickAssist. > > [DC] This is being brought to the TechBoard tomorrow (22/04) > > > > > > > > I also don't agree in classifying this as a "temporary solution" as > > > this is a solid proposal for an approach to chaining multiple > > > operations together, but I guess the fact remains that we only > > > currently have a single use-case, but it is difficult to generate a > > > generic solution in this case. > > > > > > While there is only a single use case it is targeting two devices so > > > that drove the need for a common interface withing rawdev. > > > > > > The advantage of using rawdev is that it allows this to be consumed > > > through DPDK, which enables DPDK project consumers, but also leaves > > > the door open to other contributors to have their say on how this > > > should evolve. For example this exact process seems to be occurring > > > with DMA engines in rawdev today, with a critical mass of > > > implementations which now is giving the impetus to create a generic > > > solution, as we would hope can occur here too in the future. > > > > > > > > > >>>> And the common problem here is device exposure. > > > >>>> With a specialised service on top. > > > >>>> > > > >>>> > > > >>>>>>> Here the intent is to use rawdev because we don't find a good > > API. > > > >>>>>>> API defeat is a no-go. > > > >>>>>> > > > >>>>>> [Fiona] It's not that we haven't found a good API, but that > > > >>>>>> there doesn't seem to be a general requirement for such a > > > >>>>>> specialised API > > > >>>>> > > > >>>>> There is a requirement to combine features of different classes. > > > >>>> > > > >>>> [Fiona] Can you point me to that requirement please? > > > >>> > > > >>> Yes, rte_security is trying to address this exact issue. > > > >>> > > > >> > > > >> I don't agree rte_security addresses the problem of different > > > >> device types supporting the same services. The problem being > > > >> addressed here is a single device which supports the chaining of > > > >> multiple services (sym crypto & error detection) > > > > > > > > Doing IPsec processing in Rx or Tx of a NIC is not chaining? > > > > > > I wouldn't consider an inline crypto offload or full IPsec offload a > > > chained operation in the vein being proposed here where completely > > > independent services (in the view of DPDK which are currently on > > > independent devices and APIs) are linked together. > > > > > > We did look at using rte_security here but it wasn't considered > > > suitable for a chaining of non-crypto operations such as CRC or > > > possibly compression in the future, as it would still run into the > > > issue of having to use the cryptodev enq/deq API in the lookaside offload > > case. > > > > Because rte_security is not a generic solution (that's why I don't like it). > > I think a good approach would be to check how to offload in HW the chaining > > done in frameworks like rte_pipeline or rte_graph. > > Stephen and Jerin already talked about it, but it was rejected by David, > > because harder to implement I think. > > Even worst, the team working on this patch did zero review of rte_graph. > > [DC] The team working on this patch did review rte_graph and explained our reasoning > to Jerin as to why we felt it was not suitable. No, by review, I mean doing some comments in the rte_graph series to help making the code, design or doc better. You are complaining about the lack of attention to your patch, that's why I point out that you didn't help other patches to progress. > While Jerin explained it would be possible to combine 2 nodes as a single optimized node at runtime, > he also agreed that it did NOT make sense to abstract what we are trying to do as a graph. I think this exact point requires more discussion. > Please see http://mails.dpdk.org/archives/dev/2020-March/159238.html He did not say "it does not make sense" but "In that way, it makes sense to not abstract as a graph." This is slightly different. Anyway, we should re-consider using a graph abstraction for chaining. > > I think the chaining requirement is a real problem to solve, and it deserves a > > good architecture and API. > > Maybe this future API should be based on rte_graph.