From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 9666EA0C43; Wed, 20 Oct 2021 15:34:34 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 5113F4118F; Wed, 20 Oct 2021 15:34:34 +0200 (CEST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) by mails.dpdk.org (Postfix) with ESMTP id 20AEC40142 for ; Wed, 20 Oct 2021 15:34:32 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id AB7F15C010B; Wed, 20 Oct 2021 09:34:31 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Wed, 20 Oct 2021 09:34:31 -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=fm2; bh= IXkVaM+yOE4bvWqTzMy2U76t99Y/vvEdcKG2vd9jggU=; b=RrFnn8xdxz07wGLS OwTEMroCrQQFbiFqOUrW8vBPOYanxlnUWbjhrCxs5Nwcf1ytpiX6QfYkFUvzxEhU LqfpiUUzh6z34K1i2zhalmsRHwv1VEzjlx5fR8xMYsCO99+K0d5iIwp4t8myx819 gxb8zM5TQeG8FRLJDr9KndiaKqdUGLPqEjaNkhziuwIfQ6yCvx7qj1SY8zjaI9Hh sP/wDHwvMOZdPJR9LtjTkKfxlbBHr3lkBqCcrqmkFNpANE+gPRCzmdESL5YjIBCu WEV0hS9EflIKwJwTymMOeCYB/buWrbQj4rxnMJbOv3Ql2vbT4wI3Ce3GXQx0TTqP xFi1mA== 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=IXkVaM+yOE4bvWqTzMy2U76t99Y/vvEdcKG2vd9jg gU=; b=j9+uPhOcyjBhim4yuQQTR2uv410Ui2X4cszzl7Mvx7AH+f+lo7E87ordv Y+85QW7a6aekb0xn/N/H/TZxm6hz8ZNg+WmYe7iBt+zZPuJNh7U6OGKbX0kupO6m U1JDbfQSuFjez3WX70/aAWpjhO369dgQQFf9QpGBS9q0Ban6gZe3V3kJjPrkh/ic MuJTiVEXhP33wrkMnYppzGE7VgfYZAcy8TFJ4A8KAxTGf7yuwI+0T6aW5+OpdSKT 1OqL2odsiq1OnBh3tgPfshK085BPFML3UQGQeEdUsu8nnPtB2GP2WF56dkOmmgIG B2sBIgklXoQFJ8dS/4CwZrcB2GROA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrvddvgedgiedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepudeggfdvfeduffdtfeeglefghfeukefgfffhueejtdetuedtjeeu ieeivdffgeehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 20 Oct 2021 09:34:30 -0400 (EDT) From: Thomas Monjalon To: Gagandeep Singh , Hemant Agrawal , Akhil Goyal , "Zhang, Roy Fan" Cc: "dev@dpdk.org" , "Ananyev, Konstantin" , "aconole@redhat.com" , "david.marchand@redhat.com" Date: Wed, 20 Oct 2021 15:34:28 +0200 Message-ID: <2330916.TXrJ84k8EB@thomas> In-Reply-To: References: <20211013190032.2308-1-hemant.agrawal@nxp.com> <1737616.tSrxHmIIMQ@thomas> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [EXT] Re: [PATCH v5 14/15] test/crypto: add raw API test for dpaax X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 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" Maybe I'm not clear enough. What I don't understand (and don't want to see), is specific functions for qat, ccp, nitrox or dpaa. The test should not care about the driver name. 20/10/2021 14:43, Zhang, Roy Fan: > Hi Thomas, > > The raw data path API tests takes advantage of existing cryptodev unit test > cases with one difference: > - in cryptodev sym crypto unit tests, all data is described by both rte_mbufs > and rte_crypto_ops. > - in raw data path API tests, the same data is converted from mbufs and crypto > ops into rte_crypto_sym_vec to test. > > However for each test case we can only use either crypto op way or raw data > path API way to run a test. To distinguish which way to use there is a global flag > set by test command. If you want to use crypto op way to test all cases you > use one command, otherwise with other command. > > What complicated things is, cryptodev unit test needs to prepare the data > for every test. Once the test is finished the data is either encrypted or > decrypted and cannot be reused immediately. > > Using only the device capability flag to cover both crypto op tests and raw data > path api tests in the same test function means each and every test function in > test_cryptodev.c needs to be expanded by ~30% as all data needs to be > re-prepared again for each test type. Also for the PMDs that do not support this > test type will be shown 100% more bypassed tests in the test result briefing. > > That's the reason to have this global knob so each test function only have to act > slight differently between crypto op test and raw data path API test. > > Regards, > Fan > > > -----Original Message----- > > From: Thomas Monjalon > > Sent: Wednesday, October 20, 2021 1:14 PM > > To: Zhang, Roy Fan ; Gagandeep Singh > > ; Hemant Agrawal ; Akhil > > Goyal > > Cc: dev@dpdk.org; Ananyev, Konstantin ; > > aconole@redhat.com; david.marchand@redhat.com > > Subject: Re: [EXT] Re: [dpdk-dev] [PATCH v5 14/15] test/crypto: add raw API > > test for dpaax > > > > 20/10/2021 11:32, Akhil Goyal: > > > > 20/10/2021 11:15, Akhil Goyal: > > > > > > 17/10/2021 18:16, Hemant Agrawal: > > > > > > > This patch add support for raw API tests for > > > > > > > dpaa_sec and dpaa2_sec platforms. > > > > > > > > > > > > Why do we have tests specific to some drivers? > > > > > > Is there a plan to remove them? > > > > > > > > > > > > > > > > The testsuites are common and there is no driver specific test. > > > > > The test command is different for each of the PMD, > > > > > that is why it is registered for each PMD. > > > > > For Raw data path APIs, all of the testsuite is run with a global flag set. > > > > > Currently only 3 PMDs support raw APIs, we can get rid of this global > > flag in > > > > future if more > > > > > PMDs start supporting these APIs. > > > > > > > > No there is something wrong. > > > > It shows that it is not generic enough for any app. > > > > What is missing to make the same calls no matter the driver? > > > > Do we need to add some capability flags? > > > > > > Capability flags are there for raw data path APIs but the PMD can support > > both APIs. > > > And we need to test both data paths. > > > So for this we have a global variable to enable raw data path and we > > register a new > > > Command for the PMD and enable that global flag while doing that. > > > The tests, however have the capability flags checks in place but we decide > > to enable > > > Raw APIs only when the PMD support that and that global flag is set. > > > I hope it is clear now. > > > > No sorry, it is not clear. > > How may I know that the raw API is supported in a PMD? > > If there is such info, no need for specific tests?