From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id 5F50A2FDD for ; Wed, 26 Apr 2017 11:38:23 +0200 (CEST) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Apr 2017 02:38:22 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.37,254,1488873600"; d="scan'208";a="1123611439" Received: from irsmsx107.ger.corp.intel.com ([163.33.3.99]) by orsmga001.jf.intel.com with ESMTP; 26 Apr 2017 02:38:21 -0700 Received: from irsmsx155.ger.corp.intel.com (163.33.192.3) by IRSMSX107.ger.corp.intel.com (163.33.3.99) with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 26 Apr 2017 10:38:20 +0100 Received: from irsmsx108.ger.corp.intel.com ([169.254.11.239]) by irsmsx155.ger.corp.intel.com ([169.254.14.202]) with mapi id 14.03.0319.002; Wed, 26 Apr 2017 10:38:20 +0100 From: "De Lara Guarch, Pablo" To: Akhil Goyal , "dev@dpdk.org" CC: "Doherty, Declan" , "hemant.agrawal@nxp.com" Thread-Topic: [dpdk-dev] [PATCH] test/test: improve dequeue logic for crypto operation Thread-Index: AQHSucOqnyPCrP5PiEuboN/+0R3Xq6HWDFQA Date: Wed, 26 Apr 2017 09:38:19 +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: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMmQxOTRlYmItNWM3MC00N2M4LTgwZWQtMTUwNDEzOTVkZTA1IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE1LjkuNi42IiwiVHJ1c3RlZExhYmVsSGFzaCI6IktnRTZRSDBnN2RCSVY4b1VveW9oOVRaSG5vQ2VmaXYxMEFLYmFXQmxJWkk9In0= 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 09:38:25 -0000 > -----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 cryp= to > operation >=20 > Hi Pablo, >=20 > 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 unlikel= y > 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. >=20 > The problem would arise if the underlying implementation cannot dequeue > the same number of ops as were enqueued in a single dequeue command. >=20 > 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 gradually > 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 migh= t happen on hardware. As said, I think it is OK to reuse an mbuf by two different crypto operatio= ns, 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_openssl) = 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? Thanks, Pablo >=20 > Regards, > Akhil >=20 >=20