From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by dpdk.org (Postfix) with ESMTP id EE5AA298F for ; Wed, 26 Apr 2017 12:42:34 +0200 (CEST) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga104.jf.intel.com with ESMTP; 26 Apr 2017 03:42:33 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.37,254,1488873600"; d="scan'208";a="849978819" Received: from irsmsx110.ger.corp.intel.com ([163.33.3.25]) by FMSMGA003.fm.intel.com with ESMTP; 26 Apr 2017 03:42:32 -0700 Received: from irsmsx108.ger.corp.intel.com ([169.254.11.239]) by irsmsx110.ger.corp.intel.com ([169.254.15.151]) with mapi id 14.03.0319.002; Wed, 26 Apr 2017 11:42:18 +0100 From: "De Lara Guarch, Pablo" To: Akhil Goyal , "dev@dpdk.org" CC: "Doherty, Declan" , "hemant.agrawal@nxp.com" Thread-Topic: [PATCH] test/test: improve dequeue logic for crypto operation Thread-Index: AQHSvnMDQnr+bxW7vkaz4nJ3Bx7mL6HXdUyw Date: Wed, 26 Apr 2017 10:42:17 +0000 Message-ID: References: <20170403105302.9685-1-akhil.goyal@nxp.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiOTllN2FiMmMtNjM4YS00ZDBjLWFhMTMtNWU0NzZmOTUwNzE3IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6IlFFZGRMTFZUYmJ0Z2JCcUxRd052U2g5anU1WlBtazFSOU9xNDNkUFJ5T0U9In0= x-ctpclassification: CTP_IC x-originating-ip: [163.33.239.180] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH] test/test: improve dequeue logic for crypto operation 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: , X-List-Received-Date: Wed, 26 Apr 2017 10:42:35 -0000 > -----Original Message----- > From: Akhil Goyal [mailto:akhil.goyal@nxp.com] > Sent: Wednesday, April 26, 2017 10:53 AM > To: De Lara Guarch, Pablo; dev@dpdk.org > Cc: Doherty, Declan; hemant.agrawal@nxp.com > Subject: Re: [PATCH] test/test: improve dequeue logic for crypto operatio= n >=20 > On 4/26/2017 3:08 PM, De Lara Guarch, Pablo wrote: > > > > > >> -----Original Message----- > >> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Akhil Goyal > >> Sent: Thursday, April 20, 2017 11:48 AM > >> To: De Lara Guarch, Pablo; dev@dpdk.org > >> Cc: Doherty, Declan; hemant.agrawal@nxp.com > >> Subject: Re: [dpdk-dev] [PATCH] test/test: improve dequeue logic for > crypto > >> operation > >> > >> Hi Pablo, > >> > >> On 4/4/2017 8:41 PM, De Lara Guarch, Pablo wrote: > >>> Hi Akhil, > >>> > >>>> -----Original Message----- > >>>> From: akhil.goyal@nxp.com [mailto:akhil.goyal@nxp.com] > >>>> Sent: Monday, April 03, 2017 11:53 AM > >>>> To: dev@dpdk.org > >>>> Cc: Doherty, Declan; De Lara Guarch, Pablo; Akhil Goyal > >>>> Subject: [PATCH] test/test: improve dequeue logic for crypto > operation > >>>> > >>>> From: Akhil Goyal > >>>> > >>>> While enqueue/dequeue operations in test_perf_aes_sha, > >>>> the underlying implementation may not be able to dequeue > >>>> the same number of buffers as enqueued. So, it may be > >>>> necessary to perform more dequeue operations if the gap > >>>> is more than pparams->burst_size * NUM_MBUF_SETS. > >>>> > >>>> Other algos may also need to update the logic if required. > >>>> > >>> > >>> In which way this patch improves the dequeue logic? > >>> Is it improving the performance somehow? From what I see, it is > unlikely > >> that you are going to > >>> experience the problem, as the internal ring is > PERF_NUM_OPS_INFLIGHT, > >> which is 128, > >>> higher than pparams->burst_size * NUM_MBUF_SETS, which is 256. > >>> And even if you do meet that problem, then you would be reusing > mbufs, > >>> but that is OK as we are not verifying the output. > >>> > >>> > >>> Thanks, > >>> Pablo > >>> > >> Sorry for the late response. Somehow the reply went to junk in my mail > >> client and it got missed. > >> > >> The problem would arise if the underlying implementation cannot > dequeue > >> the same number of ops as were enqueued in a single dequeue > command. > >> > >> Here we have a synchronous calls to enqueue and dequeue in the same > >> thread, so it may happen that for every enqueue of 32 ops, there are > >> lesser number of dequeue ops (say 16). There is no thread to dequeue > the > >> left over 16 ops. So the difference would increase slowly and graduall= y > >> and the application will run out of buffers. > >> So we need a mechanism to drain the left over dequeue ops. > > > > Hi Akhil, > > > > I understand, I guess that this won't happen on a software device, but > might happen on hardware. > > As said, I think it is OK to reuse an mbuf by two different crypto > operations, because we don't check the output. > > > > Anyway, it might be safer to proceed your way. Two things about it, > though: > > 1 - This should be extended to the other tests (such as test_perf_opens= sl) > for consistency. > > 2 - Since we have the test-crypto-perf app now, which cover all these > tests, I was thinking of removing test_cryptodev_perf.c, > > to avoid duplications. Any concerns on this? > > > Hi Pablo, >=20 > yes, this shall be done for other tests also, but I do not have setup to > test all of them. > And if we are planning to remove this file altogether, then we may not > need it anyway. > cperf_throughput_test_runner can alone be modified with my changes, but > I can test on NXP DPAA2 platform only. I can send the patch for this > after testing it on DPAA2 platform. For test-crypto-perf, you cannot encounter this problem, because the crypto= operation pool is the same size as the mbuf pool size, so you would run out of crypto operati= ons before hitting this problem. Thanks, Pablo >=20 > Thanks, > Akhil >=20 >=20