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 EAE6DA04AB; Wed, 6 Nov 2019 13:18:56 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 579791C10C; Wed, 6 Nov 2019 13:18:56 +0100 (CET) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) by dpdk.org (Postfix) with ESMTP id 8EFCB1C0D7; Wed, 6 Nov 2019 13:18:54 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 3CB6E21EB2; Wed, 6 Nov 2019 07:18:54 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Wed, 06 Nov 2019 07:18:54 -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=Qm/7c6cRk8qJhQob+nbe7DOPGslv8TXQ+aXH31DX2ek=; b=NmknBn+8+iMR qXjrj0amgr2Cmpy+m7TktzgZJLQVRZC+RMu++1zj5vnyLF26TQ3d5vRRAN1w/1XD RfJOYCvvnu9m+GooSQrREgKzmjye2hEyG3CWkGT0wtI78VzZw5x3T6K7ubRMJ0sC qlAsYuCPuBV4S2dvIHncx/PBvUJmUSU= 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=Qm/7c6cRk8qJhQob+nbe7DOPGslv8TXQ+aXH31DX2 ek=; b=jSbUtIkWRzfJNWWLfUTclAA08WKibnqrlV34wS9MUIb2MjHyICe7x7JXx /SwcyPXwMrjQyenAJ7b5ZyY4Wpg5iRzDqKOzHSCYJ0PhyQbJ0L5ixm9FXnOYtLJN 77FDB92aWeTV/YSyTrkrR3RnCpuvdYDI2dBm34zGYUOOi2jnY++5ksDod8m/h8z5 W45Iync4D8f2rqEDOm7/xNZ7Km/ghX4J9yr6zMMrXA3ALVF9v7ZIxTdaINg9Iv8s zKqEtgdppAmTiLVVUSPEsgYrNsbiU58eSv1ZXH8WTIomCOAtGNivbrkQz4ohcr+J MFC62CK/6y3nfLmyr6+kzekrWF4PA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedruddujedgfeelucetufdoteggodetrfdotf 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 4966C306005B; Wed, 6 Nov 2019 07:18:52 -0500 (EST) From: Thomas Monjalon To: "Ananyev, Konstantin" Cc: "techboard@dpdk.org" , Honnappa Nagarahalli , "dev@dpdk.org" , "Zhang, Roy Fan" , "Doherty, Declan" , "Akhil.goyal@nxp.com" , nd Date: Wed, 06 Nov 2019 13:18:51 +0100 Message-ID: <2859970.EjbiKIM5I0@xps> In-Reply-To: <2601191342CEEE43887BDE71AB97725801A8C80F2C@IRSMSX104.ger.corp.intel.com> References: <20191105184122.15172-1-konstantin.ananyev@intel.com> <2601191342CEEE43887BDE71AB97725801A8C80AF1@IRSMSX104.ger.corp.intel.com> <2601191342CEEE43887BDE71AB97725801A8C80F2C@IRSMSX104.ger.corp.intel.com> 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 12:33, Ananyev, Konstantin: > > > > > > > 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? > > > > Probably not... > > Because inside DPDK we don't have any other abstraction for SW crypto-libs > > except vdev, we do need dev_id to get session initialization point. > > After that I believe all operations can be session based. > > > > > So the question is to know if a synchronous API will be implemented only for CPU virtual PMDs? > > > > I don't expect lookaside devices to benefit from sync mode. > > I think performance penalty would be too high. > > After another thought, if some lookaside PMD would like to support such API - > I think it is still possible: dev_id (or just pointer to internal dev/queue structure) > can be stored inside the session itself. > Though I really doubt any lookaside PMD would be interested in such mode. So what should be the logic in the application? How the combo PMD/API is chosen? How does it work with the crypto scheduler?