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 4497CA04A2; Wed, 6 Nov 2019 10:35:19 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 7A80A1C035; Wed, 6 Nov 2019 10:35:18 +0100 (CET) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by dpdk.org (Postfix) with ESMTP id 1B3A51C034; Wed, 6 Nov 2019 10:35:17 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id A606220EAA; Wed, 6 Nov 2019 04:35:16 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Wed, 06 Nov 2019 04:35:16 -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=p3ZnDlsiZbuQBGzfrHLGy2qZTgwLFsDbuovTJ/aQpTE=; b=J/uwSOuC8KdB fBAzn1+8lse/XYpeXhL7p+tm+/1Qr7o00I87KuSMlGj9cLZX+AoWSaEUtT3cCqBl umel/UTICsDodRbPR1hMIHcs/3V4e4eERwuXWw4GyFkc95tucED02HjGiCvGBxfY 5gJa0dUwuJBkm6oKoSyubQPnURRblMQ= 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=p3ZnDlsiZbuQBGzfrHLGy2qZTgwLFsDbuovTJ/aQp TE=; b=IWW1qgSHGHeMisdqEKrB5kaEDe/+ZpAhjJI8MgcRVuJSOPVwdUdkaL7Pi tyj+FSTaf8whZS1dquWTFkUqlIDPM+uhhy14YxYkADpz61i5Co+TYLAdbiVrKVvH YrMS7L1KPLGcJqIU0DGR4Q5+74qh0sa5Dvr0UjMxY2qN0l2Pgn/Z/Dh2YxncsanY 0EpSkHx6s/XmDWLTBU5TKOaVW4NG2xFeM3z4MBi8jcGrAvICI8F7PjyGcuqg/xdb w5cPGnY5JwGTKj3viZqse/aFfFGhwVV0iiC9nWz2zupm597B1y0cAvU+BEg/4J2A a8wDH1yR3+0DliULMNmuQWo8ug3cQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedruddujedgtdehucetufdoteggodetrfdotf 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 5E64D306005B; Wed, 6 Nov 2019 04:35:14 -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:35:13 +0100 Message-ID: <14706326.cJyEje8106@xps> In-Reply-To: References: <20191105184122.15172-1-konstantin.ananyev@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 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 > > 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?