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 7D8DFA0577; Tue, 14 Apr 2020 16:44:48 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 9A2061C2E1; Tue, 14 Apr 2020 16:44:47 +0200 (CEST) Received: from new1-smtp.messagingengine.com (new1-smtp.messagingengine.com [66.111.4.221]) by dpdk.org (Postfix) with ESMTP id 7FCCB1C242 for <dev@dpdk.org>; Tue, 14 Apr 2020 16:44:45 +0200 (CEST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailnew.nyi.internal (Postfix) with ESMTP id 01ECC580265; Tue, 14 Apr 2020 10:44:42 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Tue, 14 Apr 2020 10:44:42 -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=OCI7+iT8itD7kXeiQurZB/1NoIuuIzEpEG51FRtg88Y=; b=W7kWWH/e9LUH fo7MCzeUydGGK/1rnIlxRdCURBu9U2WojPuYpTuoblqjdC6UsY9ZK2afzdnCJiW1 oqo1NSsnMQqwIasvyWNqAKhv+MAdXN5m+i1euACmdQMgUuUjuSYkK7y4oG9CpZ43 +7tFcVj0mnqPM9zAUDs4W0dui4+HcXI= 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=OCI7+iT8itD7kXeiQurZB/1NoIuuIzEpEG51FRtg8 8Y=; b=VcAXNCKn25wTvzJTi3E8hu2JHwFGDU2SzplLCsB48Y4URRMSwPQ4OHUA8 2rWAbw2dHOqrJmWC77Lgtro8qwdyh/UyBZlLcmSSUS1Dc4B3HZ5BUjyMT/sEwuaQ lN1zaTfMScq1tG5NPJw1aFOyQIdf4muGW11I03O3EIf/f9gq9f3s6aP2MyxrswgS ha6EQoj1CoR9DUwWe934EHz8ho2cHeD1qzvzBzNpbBnAH1Uyxgr2HKDcAONArdyN YAPQf+JEVIwK0cUTrrEAKAy6hdBisYYXDwRqYRLo349JFWEQfSHfHABqiLmjWbAj avIWLerCABuuQeLFmGIua3aP6T5aw== X-ME-Sender: <xms:WMyVXnj9rW2uUoX1WIssqqk1qauhttW9WBdw1k-SxeHoyc2RrJcgOg> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrfedugdejlecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghs ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucffoh hmrghinhepughpughkrdhorhhgpdhouhhtlhhoohhkrdgtohhmnecukfhppeejjedrudef gedrvddtfedrudekgeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrih hlfhhrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght X-ME-Proxy: <xmx:WMyVXl4UM-pkVdJphs4dAyN8pPsJZACdltxq8fcLm1PvhGLb41ta5Q> <xmx:WMyVXsNREtiDYXfwmkjky2rXCD9nM8c-hUDQd34oLSny0GvTJ_giiQ> <xmx:WMyVXkdr1zit8SWPcohUzxmkPuWjVGqkXefdcW2Nodjdehzkl8YYGg> <xmx:WcyVXjcPSfX2gCqRSYLGl2Npdk-DLN-GEKKydLJmjYvKEezPb1djyA> Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id BAC193280065; Tue, 14 Apr 2020 10:44:38 -0400 (EDT) From: Thomas Monjalon <thomas@monjalon.net> To: "Yigit, Ferruh" <ferruh.yigit@intel.com>, "Trahe, Fiona" <fiona.trahe@intel.com> Cc: "Coyle, David" <david.coyle@intel.com>, "dev@dpdk.org" <dev@dpdk.org>, "Doherty, Declan" <declan.doherty@intel.com>, "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>, "Trahe, Fiona" <fiona.trahe@intel.com> Date: Tue, 14 Apr 2020 16:44:27 +0200 Message-ID: <4421330.vfdyTQepKt@thomas> In-Reply-To: <SN6PR11MB288086FD51ED31D11619580EE4DA0@SN6PR11MB2880.namprd11.prod.outlook.com> References: <20200410142757.31508-1-david.coyle@intel.com> <5745012.CvnuH1ECHv@thomas> <SN6PR11MB288086FD51ED31D11619580EE4DA0@SN6PR11MB2880.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> 14/04/2020 16:02, Trahe, Fiona: > Hi Thomas, > > 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? > > [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. > 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. > 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.