From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id C1828A0350; Tue, 30 Jun 2020 23:00:55 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 09F071BF6D; Tue, 30 Jun 2020 23:00:55 +0200 (CEST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) by dpdk.org (Postfix) with ESMTP id 4B2CE1BF5E; Tue, 30 Jun 2020 23:00:53 +0200 (CEST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 643CF5C0115; Tue, 30 Jun 2020 17:00:52 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Tue, 30 Jun 2020 17:00:52 -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= oUvJ4QjuKmrJDFcGamdxyAMclaEk+M6Y2zEVcgk0qM4=; b=Blzwqah4fg/I2i7I uFE6d6whwLbvtHeafKkGy0FvqBmMVEeRg3fL3QpT4sEq89V0vSLHedZiBk29+RpC ROQt4+VR7/dTL7ZMLzRD5wv1ODEcRMQfEWvsLeN0dmfBBMeswtacvaLtHTJLfWYh AFTVUbNLwNfzhY7+VjfTOCjP4DbPyGuAboUq1dfI21n6g+c3x5+sXZc7YlkwhJ2h T2l53m0TxVyhJ8bujppFj288hoCcu3fjo9i22isqHCck2j+Mnp5FIwdh71cfDM7S QAc7jCK2825uj8KmNG3F35MlMO2L9UQgS9OexRqK+lDJraz2ZsJnsWPNSdFgs9+x +62Niw== 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=fm3; bh=oUvJ4QjuKmrJDFcGamdxyAMclaEk+M6Y2zEVcgk0q M4=; b=QV0Pkotpqer8PnjIRJoyhxeMxQ7ItwaZ4m2RUGAIHN0QibESLNEudPpff k+k5/19lR4I8V2LVzaDUcsftDO322yduuRLDcOFjpB5/LK2p9aN/o015sL8i98Wi pu8OCGvAPsC1T6wR2OVh24B5RniptrY9L2JhthVAGVvuLBlYaOBCz2gMCJ2aUgCz tNqxsbr/wWrt/NmwGS2W1CeLtOBgK/HbpqWKMDO78XS4QPOj6QonKH/rN/AiRpA7 U4FES6l7uXtxlg1njhsYObg+i3myCUd1Zj7gnTnJk1Rpc4gFiSuOKw1aBXHDrg0t yS1b40oKWNuF5sQ4tnf8Xp4wW85Ow== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrtddtgdduvdejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtqhertddttdejnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepudevvddtvdetudegudetleeuueegleeuveelkefhgfffvdeludej hfejjeduhfdvnecuffhomhgrihhnpehstghhvggurdgtohhmnecukfhppeejjedrudefge drvddtfedrudekgeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhl fhhrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 2ED013280059; Tue, 30 Jun 2020 17:00:49 -0400 (EDT) From: Thomas Monjalon To: Honnappa Nagarahalli Cc: Fan Zhang , "techboard@dpdk.org" , Jerin Jacob , Anoob Joseph , dpdk-dev , "Akhil.goyal@nxp.com" , Fiona Trahe , Piotr Bronowski , nd Date: Tue, 30 Jun 2020 23:00:46 +0200 Message-ID: <2108694.aBCEnuStHj@thomas> In-Reply-To: References: <20200612143940.52851-1-roy.fan.zhang@intel.com> <6794037.dnW9c1l1XM@thomas> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [dpdk-techboard] [PATCH] crypto/qat: add data-path APIs X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 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" 30/06/2020 22:33, Honnappa Nagarahalli: > 26/06/2020 12:38, Thomas Monjalon: > > 26/06/2020 08:55, Jerin Jacob: > > > On Fri, Jun 12, 2020 at 8:10 PM Fan Zhang w= rote: > > > > > > > > This patch adds data-path APIs to QAT symmetric dirver to support > > > > raw data as input. > > > > > > > > For applications/libraries that want to benefit from the data-path > > > > encryption acceleration provided by QAT but not necessarily depends > > > > on DPDK data-path structures (such as VPP), some performance > > > > degradation is unavoidable to convert between their specific data > > > > structure and DPDK cryptodev operation as well as mbufs. > > > > > > > > This patch takes advantage of existing QAT implementations to form > > > > symmetric data-path enqueue and dequeue APIs that support raw data > > > > as input so that they can have wider usability towards those > > > > applications/libraries without performance drop caused by the data > > > > structure conversions. In the meantime the less > > > > performance-sensitive cryptodev device and session management > > > > remains intact so that DPDK cryptodev remains to be unified control= path > > library for QAT. > > > > > > > > Signed-off-by: Fan Zhang > > > > Signed-off-by: Piotr Bronowski > > > > --- > > > > > > + Techboard, > > > > > > I think, this problem is not specific to QAT nor the crypto subsystem. > > > If we are planning to expose the PMD specific descriptors, It would > > > good to get general agreement from everyone. Probably we can/need to > > > extend ethdev PMDs as well based on the need. > > > > > > If we are taking this path, at minimum, we need a generic control path > > > API with cryptodev, to query such capability. (Probably API to > > > register descriptor and query supported descriptor as PMD can support > > > multiple descriptors) > >=20 > > I fully agree, it needs to be a community decision. > +1 >=20 > >=20 > > Today, if an application wants to use DPDK, either it adopts mbuf, or i= t pays > > the cost of mbuf conversion. > >=20 > > The question is: can DPDK provides helpers for a non-mbuf datapath? > >=20 > > The benefit is clear for applications which are not mbuf-centric. > Agree, this was captured in [1] >=20 > [1] https://dpdkna2019.sched.com/event/WYBw/custom-meta-data-in-pmds-honn= appa-nagarahalli-arm >=20 > The other benefit is that, projects like VPP do not have to maintain thei= r own driver code. So, at a big picture level, we (the humanity =F0=9F=98= =8A) save on effort. >=20 > >=20 > > The disadvantages I can think about: > > - Opening a new API layer is adding more work for everybody > > (development, test, maintenance). > Documentation to capture descriptor format. >=20 > > - Applications must duplicate a part of the DPDK datapath. > > - Lack of consistency between the configuration APIs > > and the datapath implemented by the application. >=20 > I did not understand this, can you please elaborate? > Since the datapath is completely implemented in the application, the resp= onsibility of keeping it updated with the features added by the configurati= on APIs remains with the application. If you update a PMD strategy in a configuration step, the app datapath can become out of sync.