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 A05BAA0588; Thu, 16 Apr 2020 00:33:15 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id E070A1D722; Thu, 16 Apr 2020 00:33:14 +0200 (CEST) Received: from new2-smtp.messagingengine.com (new2-smtp.messagingengine.com [66.111.4.224]) by dpdk.org (Postfix) with ESMTP id E84FB1D715 for <dev@dpdk.org>; Thu, 16 Apr 2020 00:33:13 +0200 (CEST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailnew.nyi.internal (Postfix) with ESMTP id 7E68A580304; Wed, 15 Apr 2020 18:33:13 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Wed, 15 Apr 2020 18:33:13 -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=mesmtp; bh=r26f5mbUSIomKC6XfAkovHEOxqvMS/ZkuSx4QZD8tV8=; b=AP/Hv2ihHVx3 BbaFPzmqNCKdXw9WVfeF1wnZbcvOR/rcZs1pbJ/PXMm5kGuWUq7RrgEc0yigIyX9 Fhj4lG791K0F5jV6WsnZ50EalS/fZh3ByrZmbZaV6vzT1nWX7CcgcMVjT/cY+ywR pWC9JRmmB3KYgXsWo/K4LW/J01Pm068= 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=r26f5mbUSIomKC6XfAkovHEOxqvMS/ZkuSx4QZD8t V8=; b=dg6Rry4pEnCOwrvHEdoVTOnBNVm8ghoMWQAMqOaTp49/6tndpmw40wQfi yQb1DrvV97FU0+dwQ3W5K/gK5o/AzQi4WXuXaA4AHdRhgL0OiIw192MGb6Q67g0Y 6bC3ANZnwECWKL0EoizK/68OtfFQVHGpiY10qWDkH1Rns4LLY72MQP/f94ubQX64 xtNMgKBUx/fCfk86hOjGCEENLF7bBR/KO9iwElsh/r88JSF9HtGWdAspAQZyIEbu aleCi0MYgx24jnl86PE/yGbMBCBGbPglQRaaRWvlSoIu9YnVbozEYgwY7R9UwBGX 9dLKpMsBVV5k6lQqto9jWFj3m2biw== X-ME-Sender: <xms:qIuXXiaWRXr6jiG0K49SquzKTUqfRbtnOIWrleVUN_3MeIG0eq_hYg> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrfeeggdduudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghs ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucffoh hmrghinhepughpughkrdhorhhgpdhouhhtlhhoohhkrdgtohhmnecukfhppeejjedrudef gedrvddtfedrudekgeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrih hlfhhrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght X-ME-Proxy: <xmx:qIuXXn_yQiY61loeAsZXPK-B8jq8OO3e5FnIw62flJohP8__dRSOkg> <xmx:qIuXXgkvkabyJprteTtyTmv3ws2HdjTBwBC6LPiOQ3DqbbiE3IFLsA> <xmx:qIuXXkzS65MsknnShSb7EBzh3XMU0ZXlfDb1n2sRq43LxM0020Xy9w> <xmx:qYuXXk4AU3wpiAigNznSmE-eDKskmwERqzUj7UfXHD3hwyqQC4zy-A> Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 2F1943280065; Wed, 15 Apr 2020 18:33:10 -0400 (EDT) From: Thomas Monjalon <thomas@monjalon.net> To: "Yigit, Ferruh" <ferruh.yigit@intel.com>, "Trahe, Fiona" <fiona.trahe@intel.com>, "Doherty, Declan" <declan.doherty@intel.com> Cc: "Coyle, David" <david.coyle@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, honnappa.nagarahalli@arm.com, Stephen Hemminger <stephen@networkplumber.org>, alexr@mellanox.com Date: Thu, 16 Apr 2020 00:33:09 +0200 Message-ID: <8017884.aoefvbuG5b@thomas> In-Reply-To: <2fa52616-2e81-4eae-a28b-4549154742fe@intel.com> References: <20200410142757.31508-1-david.coyle@intel.com> <4421330.vfdyTQepKt@thomas> <2fa52616-2e81-4eae-a28b-4549154742fe@intel.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> 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? > >> 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? > >> We suggested it, but did not get community engagement and have > >> dropped our generic API requirement, instead focussing on this specialised case. > > > > I did not see such generic proposal, sorry. > > > >>> In the past, rte_security was an "answer" to this issue with crypto and ethdev. > >>> This is a real topic, please let's find a generic elegant solution.