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 64516A0350; Fri, 26 Jun 2020 12:38:56 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 483581BED0; Fri, 26 Jun 2020 12:38:56 +0200 (CEST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) by dpdk.org (Postfix) with ESMTP id 4843F1BECB; Fri, 26 Jun 2020 12:38:54 +0200 (CEST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id E1EFA5C00B8; Fri, 26 Jun 2020 06:38:53 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Fri, 26 Jun 2020 06:38:53 -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= UQhBW782z3nPo/sTZoJr/Xqes6H8gtAMz/RtzkVWK+U=; b=ukvvt2zPTAyllqi7 a/NPdWClKtlu2hoLvRVGrN5xopbhiHN1b9QeJYKoqwTVbfF4fwkGzeLR0c/6APK+ +NRD74492IA20aboqf28h7Lul5ntX+UxMN/+SAX9PYsIMIdsvPaE9ZGQNOyYkmBn 9R7KhAn9ybL2jqa4I6gthkdks9A0iAULYbWePjLszzwaQgKfICGPCV/Vq2qSaOeR 7+nU2JU4qyqtZnSULEXMlwGo5eL7chH4vncshqu7Ndx1OKDTvrGUCzFTWJ8VL5r4 z1IPbHW+Qge7cHSFLbGTH+qIiSVfin7QTWBIv7AA3530sP7YuXV2wElodLUo3vFb DR7JIA== 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=UQhBW782z3nPo/sTZoJr/Xqes6H8gtAMz/RtzkVWK +U=; b=rmrCafNRRI53o9keAYTxQbH4876RnsXeTGjIKJUH7Vb9YiJneLhekQivi ncPJmmr748x/wFaLxow9RZIeat9JvuQpLYxDjhhGwR+31kceXuKsYYnyphFnlppx beh2oEJ8PoewbXJbSid5TwihZYMO7Ym0PB0/wF1iY14Lu3/001iZmSWzgFq95DFD XL5m58wFC7WHkHDiBNHHNfde+TNorpz/UlFsu72Fg0xKFeCdTPrjmcXcQ/Tvmp3Z HHtFzlAcJNu9f3gAaWH94W4VEX0yoV1aDWEBnbyYT27CB+fZ1qSXDhC8ooLX8VGt aEpxxGlblCDPAVchxDLUURHlf8K7A== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudeluddgfedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepudeggfdvfeduffdtfeeglefghfeukefgfffhueejtdetuedtjeeu ieeivdffgeehnecukfhppeejjedrudefgedrvddtfedrudekgeenucevlhhushhtvghruf hiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehthhhomhgrshesmhhonhhjrghl ohhnrdhnvght 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 59739328005A; Fri, 26 Jun 2020 06:38:52 -0400 (EDT) From: Thomas Monjalon To: Fan Zhang , techboard@dpdk.org, Jerin Jacob Cc: Anoob Joseph , dpdk-dev , Akhil Goyal , Fiona Trahe , Piotr Bronowski , honnappa.nagarahalli@arm.com Date: Fri, 26 Jun 2020 12:38:51 +0200 Message-ID: <6794037.dnW9c1l1XM@thomas> In-Reply-To: References: <20200612143940.52851-1-roy.fan.zhang@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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" 26/06/2020 08:55, Jerin Jacob: > On Fri, Jun 12, 2020 at 8:10 PM Fan Zhang wrote: > > > > 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) I fully agree, it needs to be a community decision. Today, if an application wants to use DPDK, either it adopts mbuf, or it pays the cost of mbuf conversion. The question is: can DPDK provides helpers for a non-mbuf datapath? The benefit is clear for applications which are not mbuf-centric. The disadvantages I can think about: - Opening a new API layer is adding more work for everybody (development, test, maintenance). - Applications must duplicate a part of the DPDK datapath. - Lack of consistency between the configuration APIs and the datapath implemented by the application.