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 BD601A0526; Wed, 8 Jul 2020 15:38:00 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 1B0381DDD2; Wed, 8 Jul 2020 15:37:53 +0200 (CEST) Received: from new4-smtp.messagingengine.com (new4-smtp.messagingengine.com [66.111.4.230]) by dpdk.org (Postfix) with ESMTP id CC6D11D6F6 for ; Wed, 8 Jul 2020 15:37:50 +0200 (CEST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailnew.nyi.internal (Postfix) with ESMTP id 7D7DC58039C; Wed, 8 Jul 2020 09:37:48 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Wed, 08 Jul 2020 09:37:48 -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= mXisbWEny9nmuZPyC1vqm/LTJc2aHH/fSZ/cZaZwcXU=; b=nPKfXRudw4/DuiNU xWK9FdPlkpBBF/Vk7bEhg6CZLjdhqWRmiN0/Yc3DB7hdJ4QsFTFU/1vJxJMzzJT7 x6/6iqEvmZuF00P9h19esLfSumUOyHLgxdUay+DvLOYBHrQbaEpVhgUCu83z2VuO 9gdzuqyqbOdG+Syzdo1jj5jyzkpEJsAkJNiU6lcuemX6Qc4SJGtnXCgF+tEPUfkn vh45FpUIAwv6LKYEcq2QmyXkcQ6gHl5fq+NM+CLB9QDix4JBAmde7q+pJk1ckJ/t bqGFZSR/IeDeasadKzwAkuI7+PoMq1lyQmTzdpNW9qsUphtoYS0zPMsT738Vq5j1 1vU4DA== 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=mXisbWEny9nmuZPyC1vqm/LTJc2aHH/fSZ/cZaZwc XU=; b=CJ+cWGiJp924tML7txcMFxi4osWbpKvo/87DoIDgiT/qvUreupJPKGG9O fGXPs8+bJE/m214PUr1rXk8hEVzb9FNGUsSwKsi6wf/sCssDRURJM9NHrl5XpcUk aYHsIFhwXsbRFB6UdP9m4ybpW7Z+M4WNUM+DHuwb3yaKwa+rk1YmgP0G/EGt20Wx 7+lh0xbzDcXe9LQArIEn8srFzJlO/uItsipr0seCzQs34ptiGOXZRQ5E3fhQvRGh Vbghrk8PSJK4Q9nQmdRfGT6LIXySnr5KVWA5C4uPRndErRU3mtJDdob7YNAMu7wP zlaL61IMJvBaG/a+k2TA5ynGenCLA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrudejgdeijecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhephffvufffkfgjfhgggfgtsehtufertd dttddvnecuhfhrohhmpefvhhhomhgrshcuofhonhhjrghlohhnuceothhhohhmrghssehm ohhnjhgrlhhonhdrnhgvtheqnecuggftrfgrthhtvghrnhepudeggfdvfeduffdtfeegle fghfeukefgfffhueejtdetuedtjeeuieeivdffgeehnecukfhppeejjedrudefgedrvddt fedrudekgeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhroh hmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght 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 0FBB430600A3; Wed, 8 Jul 2020 09:37:45 -0400 (EDT) From: Thomas Monjalon To: akhil.goyal@nxp.com, fiona.trahe@intel.com, arkadiuszx.kusztal@intel.com Cc: dev@dpdk.org, ferruh.yigit@intel.com, bruce.richardson@intel.com, orika@mellanox.com, jerinj@marvell.com, stephen@networkplumber.org, olivier.matz@6wind.com, hemant.agrawal@nxp.com, mdr@ashroe.eu Date: Wed, 08 Jul 2020 15:37:44 +0200 Message-ID: <1939387.ZpZeW6HBnj@thomas> In-Reply-To: <20200624142653.16488-1-arkadiuszx.kusztal@intel.com> References: <20200624142653.16488-1-arkadiuszx.kusztal@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v2] cryptodev: add function to check if qp was setup 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" 24/06/2020 16:26, Arek Kusztal: > From: Fiona Trahe > > This patch adds function that can check if queue pair > was already setup. This may be useful when dealing with > multi process approach in cryptodev. That's all? No more justification? No usage in example apps? No addition in test apps? Is it needed for the application? I don't know cryptodev enough, but I can tell with ethdev experience that we are a lot more demanding when adding a new API in ethdev. We are still fixing the API errors done years ago in ethdev, and it is very difficult to deprecate what was used in the past. I hope my fear is wrong and you are not doing the same errors as we did in ethdev, it would be a pity.