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 A19C6A0562; Thu, 2 Apr 2020 22:51:34 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id D62101C02A; Thu, 2 Apr 2020 22:51:33 +0200 (CEST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by dpdk.org (Postfix) with ESMTP id 8804C1C027 for ; Thu, 2 Apr 2020 22:51:32 +0200 (CEST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 1F3905C003F; Thu, 2 Apr 2020 16:51:32 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Thu, 02 Apr 2020 16:51:32 -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=mesmtp; bh=FaSZ9jylyB9YUlvn5L0iaJIvshO48a9oUUUgna+Y3Ng=; b=c6RaxKBz1045 pEAzGk1bk8ylusKUoeHq9sUqZjYKXNzWjHehWHDDfW2GChy12u0aOkRE+wn/Q4RG 9PU7BJSZUvTuMsEE5qnmLfqvXmLO9pA6ps0gYbiJlDqS9w9LNrg4ZzEVTbRKa63y J8iSi8IGVUtUwNwCG2VP/lPz/2Q0FnE= 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=fm2; bh=FaSZ9jylyB9YUlvn5L0iaJIvshO48a9oUUUgna+Y3 Ng=; b=KkdCnCESRhsvOC0PbGQbVIqRqhAZkTta6ij55Kndjn+5TlozvoPETj399 4WrUMo6EOSB1Jlq0t1omcQT/pcDV/wWOlSCjJQzqUjenWACnGdvC1VhzKRd2+VTs laL6JRyWs7CdHgyXGM50QgodqazKJpS+NOsPLC5ej2P+HVd56jxx1BWjcWlaOa4D eO+qM7kWeEqvVZhS/hWr0QFqDutIdqgkqWejO6IytJ2P8WZX/w+C5wWbVn5tmM1L YpPsB7jMTyhwOdaiSXPFyEkpJcf5GCB0qD8pSJXAWQG0PzLVOSpE5nbxn8aMw+p6 ouacij/4dGJN4ihgmvovhUgiE5qJw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrtdeggddugeefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecukf hppeejjedrudefgedrvddtfedrudekgeenucevlhhushhtvghrufhiiigvpedtnecurfgr rhgrmhepmhgrihhlfhhrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght 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 8E762306CE7C; Thu, 2 Apr 2020 16:51:30 -0400 (EDT) From: Thomas Monjalon To: Lukasz Wojciechowski Cc: Akhil Goyal , "declan.doherty@intel.com" , dev@dpdk.org Date: Thu, 02 Apr 2020 22:51:29 +0200 Message-ID: <2472209.CFs8Y8CuNP@xps> In-Reply-To: <43a9be22-ee6a-3744-3a05-858eeee313a1@partner.samsung.com> References: <20200312151654.7218-1-l.wojciechow@partner.samsung.com> <1703484.4MS8fQxZnU@xps> <43a9be22-ee6a-3744-3a05-858eeee313a1@partner.samsung.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH 05/13] app/test: introduce librte_security tests 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" 02/04/2020 21:49, Lukasz Wojciechowski: > > W dniu 01.04.2020 o 19:51, Thomas Monjalon pisze: > > 01/04/2020 19:09, Akhil Goyal: > >> Hi Lukasz, > >> > >>> This patch introduces set of unit tests of librte_security API functions. > >>> Tests are added to dpdk-test application and can be run with > >>> "security_autotest" runtime command. > >>> > >>> This is the first patch in the series of patches as adding all test cases > >>> for all API functions in a single patch would make it unreadable. > >>> > >>> This patch defines structure of the file and necessary test framework > >>> initialization. It also contains first subset of unit tests for > >>> rte_security_session_create API function. > >>> > >>> Structure of the tests file is following: > >>> - macros for making tests more readable; > >>> - mockup structures and functions for rte_security_ops; > >>> - test suite and test cases setup and teardown functions; > >>> - tests functions; > >>> - declaration of testcases. > >>> > >>> Signed-off-by: Lukasz Wojciechowski > >>> Change-Id: I3a4585f56ef1a75b2984fcea3a3e4a30e4c2d8a6 > >>> --- > >> This patchset has a lot of repeated(for each API) tests just to check the input parameters to > >> Rte_security APIs. I am not sure what value addition is done to separate out each API as a separate > >> Negative Test. Instead a single case can be added to test all APIs with inappropriate arguments. > >> We should add more positive cases with proper session parameters. > >> > >> Thomas, > >> Do we allow these type of test cases in other modules? > > I did not review these patches, but I think we can try to compare > > with tests done on eventdev library. > > It would be interesting to have an opinion from Declan. > > > > These rte_security tests look quite big. > > However I don't know what is too big for test code? > > Lukasz, please could you explain the initial motivation when writing > > these tests? Are you especially interested in rte_security? > > Or do you plan to reproduce this effort on other libraries? > > > > > Hi Akhil and Thomas, > > I've just started using dpdk this year and was writing few small apps to > get familiar with API. > I noticed few things that can be fixed in the security lib and though > that they can be fixed easily, so I prepared patches. > > After that I searched for some unit tests of the lib to add some tests > that cover my code. I always try to do so > and when I found no tests for security lib I made some. > > I don't know if you need them or is this the right place to put them, > but I did. And as I made the tests I tried to cover 100% code of > security lib. > > Currently I don't have any plans to add or change anything in > rte_security. These patches are just a "collateral damage" to my process > of learning dpdk and a strong believe that if you can share some fixes > you should do it, because that the open source power. > > So it is totaly up to you, what we can do with these patches. I would be > glad to work on them and change them the way you think they should look > like, e.g. I can squash all the parameters checks to a single negative > case as you, Akhil suggested. If you would like to see similar patches > in other libraries I can help with that in some spare time. I'm the new > guy here, so please guide me a bit ;) Thanks a lot Lukasz. In general we need more tests in DPDK. I won't be able to review these patches myself, so I hope many developers will review and guide you. My advice is to review at least one or two other patchsets. Hopefully someone will do the same for you. If it does not work, please ping Akhil and me. As a last resort, we could prioritize merging patches of contributors helping others.