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 6828BA04A2; Wed, 6 Nov 2019 10:48:13 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id A0A631C025; Wed, 6 Nov 2019 10:48:12 +0100 (CET) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by dpdk.org (Postfix) with ESMTP id 4F1031C01E; Wed, 6 Nov 2019 10:48:10 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 6393C22028; Wed, 6 Nov 2019 04:48:09 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Wed, 06 Nov 2019 04:48:09 -0500 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=vbQgovwvabBorBsltDm1nxQ1mTmxn10qR+/reOc1oMA=; b=YeUdQQaNBSa4 S2iOqGUfmm9pnjGysIXa3P+15kIVebfXnNlL2kMfP7lsrBMy0XZHbvGozbafsEpY LVQIxcJQjNFnSSJ/vVI2vKwtT7mPNoobgFs3SVbJSFKG+jVLk4Z4xArU6YQyBo8I eFRbjJB9B3Wr7A3Fl/W2OO2KXOV2PPs= 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=fm1; bh=vbQgovwvabBorBsltDm1nxQ1mTmxn10qR+/reOc1o MA=; b=Qn8K7Sbz+SWAF/K5rfDhL2o+VWZFdeJAYYFeoKoUhqYJ5QVO9MsWCQ3id 7LxdOm5jbKZehpKz54orDw+nq+l3iCrweu2ERBk1chHpFqZzHFdeI955z0DN+jxt 4oH6pF8yLDPczmivTbicvV3XIItc8Ajkt6soxBv1JdWR01EoGCElmljw/UMs5dPU f8KYWBYF3PSdXm+anO+HIVGykfxw50bPlELpZh7NwL3+KmQ3jAB/19W+Kcxwo3dK Snboi1Biukc9IOO4mwCkY6kUgNMjm+PxVV1x5AvllTmZQxfEm9Cy5QLrIAqE4cpv ZsMQg40VSicM8wcLkGxg/C4yrZS/Q== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedruddujedgtdekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecukf hppeejjedrudefgedrvddtfedrudekgeenucfrrghrrghmpehmrghilhhfrhhomhepthhh ohhmrghssehmohhnjhgrlhhonhdrnhgvthenucevlhhushhtvghrufhiiigvpedt 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 B9D6E306005B; Wed, 6 Nov 2019 04:48:07 -0500 (EST) From: Thomas Monjalon To: techboard@dpdk.org Cc: Honnappa Nagarahalli , Konstantin Ananyev , "dev@dpdk.org" , "roy.fan.zhang@intel.com" , "declan.doherty@intel.com" , "Akhil.goyal@nxp.com" , nd Date: Wed, 06 Nov 2019 10:48:06 +0100 Message-ID: <2392085.VtZaC0aJ27@xps> In-Reply-To: <14706326.cJyEje8106@xps> References: <20191105184122.15172-1-konstantin.ananyev@intel.com> <14706326.cJyEje8106@xps> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [dpdk-techboard] [RFC 0/4] cpu-crypto API choices 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" 06/11/2019 10:35, Thomas Monjalon: > 06/11/2019 05:54, Honnappa Nagarahalli: > > > > > > > Originally both SW and HW crypto PMDs use rte_crypot_op based API to > > > process the crypto workload asynchronously. This way provides uniformity to > > > both PMD types, but also introduce unnecessary performance penalty to SW > > > PMDs that have to "simulate" HW async behavior (crypto-ops > > > enqueue/dequeue, HW addresses computations, storing/dereferencing user > > > provided data (mbuf) for each crypto-op, etc). > > > > > > The aim is to introduce a new optional API for SW crypto-devices to perform > > > crypto processing in a synchronous manner. > > > As summarized by Akhil, we need a synchronous API to perform crypto > > > operations on raw data using SW PMDs, that provides: > > > - no crypto-ops. > > > - avoid using mbufs inside this API, use raw data buffers instead. > > > - no separate enqueue-dequeue, only single process() API for data path. > > > - input data buffers should be grouped by session, > > > i.e. each process() call takes one session and group of input buffers > > > that belong to that session. > > > - All parameters that are constant accross session, should be stored > > > inside the session itself and reused by all incoming data buffers. > > > > > > While there seems no controversy about need of such functionality, there > > > seems to be no agreement on what would be the best API for that. > > > So I am requesting for TB input on that matter. > > > > > > Series structure: > > > - patch #1 - intorduce basic data structures to be used by sync API > > > (no controversy here, I hope ..) > > > [RFC 1/4] cpu-crypto: Introduce basic data structures > > > - patch #2 - Intel initial approach for new API (via rte_security) > > > [RFC 2/4] security: introduce cpu-crypto API > > > - patch #3 - approach that reuses existing rte_cryptodev API as much as > > > possible > > > [RFC 3/4] cryptodev: introduce cpu-crypto API > > > - patch #4 - approach via introducing new session data structure and API > > > [RFC 4/4] cryptodev: introduce rte_crypto_cpu_sym_session API > > > > > > Patches 2,3,4 are mutually exclusive, > > > and we probably have to choose which one to go forward with. > > > I put some explanations in each of the patches, hopefully that will help to > > > understand pros and cons of each one. > > > > > > Akhil strongly supports #3, AFAIK mainly because it allows PMDs to reuse > > > existing API and minimize API level changes. > > > > IMO, from application perspective, it should not matter who (CPU or an accelerator) does the crypto functionality. It just needs to know if the result will be returned synchronously or asynchronously. > > We already have asymmetric and symmetric APIs. > Here you are proposing a third method: symmetric without mbuf for CPU PMDs Sorry, for this garbage, I am mixing synchronous/asynchronous and symmetric/asymmetric. > > > My favorite is #4, #2 is less preferable but ok too. > > > #3 seems problematic to me by the reasons I outlined in #4 patch description. > > > > > > Please provide your opinion. > > It means the API is not PMD agnostic, right? So the question is to know if a synchronous API will be implemented only for CPU virtual PMDs?