From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0067.outbound.protection.outlook.com [104.47.32.67]) by dpdk.org (Postfix) with ESMTP id E69EE592B for ; Mon, 11 Sep 2017 14:59:45 +0200 (CEST) Received: from DM5PR03CA0058.namprd03.prod.outlook.com (10.174.189.175) by MWHPR03MB3328.namprd03.prod.outlook.com (10.174.249.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.35.12; Mon, 11 Sep 2017 12:59:44 +0000 Received: from BL2FFO11OLC008.protection.gbl (2a01:111:f400:7c09::137) by DM5PR03CA0058.outlook.office365.com (2603:10b6:4:3b::47) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.35.12 via Frontend Transport; Mon, 11 Sep 2017 12:59:44 +0000 Authentication-Results: spf=fail (sender IP is 192.88.168.50) smtp.mailfrom=nxp.com; intel.com; dkim=none (message not signed) header.d=none;intel.com; dmarc=fail action=none header.from=nxp.com; Received-SPF: Fail (protection.outlook.com: domain of nxp.com does not designate 192.88.168.50 as permitted sender) receiver=protection.outlook.com; client-ip=192.88.168.50; helo=tx30smr01.am.freescale.net; Received: from tx30smr01.am.freescale.net (192.88.168.50) by BL2FFO11OLC008.mail.protection.outlook.com (10.173.160.143) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_RSA_WITH_AES_256_CBC_SHA) id 15.20.13.11 via Frontend Transport; Mon, 11 Sep 2017 12:59:44 +0000 Received: from [10.232.14.39] ([10.232.14.39]) by tx30smr01.am.freescale.net (8.14.3/8.14.0) with ESMTP id v8BCxeZI017521; Mon, 11 Sep 2017 05:59:41 -0700 To: "De Lara Guarch, Pablo" , Akhil Goyal CC: "Doherty, Declan" , "Trahe, Fiona" , "Jain, Deepak K" , "Griffin, John" , "jerin.jacob@caviumnetworks.com" , "hemant.agrawal@nxp.com" , "dev@dpdk.org" References: <20170818080520.43088-1-pablo.de.lara.guarch@intel.com> <20170818080520.43088-7-pablo.de.lara.guarch@intel.com> <9F7182E3F746AB4EA17801C148F3C60433039119@IRSMSX101.ger.corp.intel.com> From: Shreyansh Jain Message-ID: Date: Mon, 11 Sep 2017 18:40:41 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-Matching-Connectors: 131496083843585860; (91ab9b29-cfa4-454e-5278-08d120cd25b8); () X-Forefront-Antispam-Report: CIP:192.88.168.50; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10009020)(6009001)(336005)(39380400002)(39860400002)(2980300002)(1110001)(1109001)(3190300001)(339900001)(377454003)(199003)(189002)(51914003)(24454002)(13464003)(33646002)(2906002)(23676002)(106466001)(65806001)(81166006)(65956001)(47776003)(36756003)(81156014)(6636002)(68736007)(6246003)(83506001)(356003)(8936002)(85426001)(105606002)(4326008)(53546010)(53936002)(93886005)(230700001)(8656003)(54906002)(229853002)(50466002)(86362001)(189998001)(77096006)(31696002)(64126003)(97736004)(65826007)(31686004)(8676002)(104016004)(2950100002)(4001350100001)(5660300001)(305945005)(76176999)(54356999)(50986999)(498600001); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR03MB3328; H:tx30smr01.am.freescale.net; FPR:; SPF:Fail; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11OLC008; 1:rziFSbzVT91lhuYqMtUqDt63qFXd/yzdbUg73QCXRLWuzXdr/yaBaFYfVCAAhTsY9FIDZNzJ6sgr7LqsjRNA2deVmc1Yf4+xjzDod51NWcA72re4Uayy5RmLyNvaCA+g X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 85de3453-a970-4909-b5e7-08d4f914f94e X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(300000503095)(300135400095)(2017052603199)(201703131430075)(201703131517081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:MWHPR03MB3328; X-Microsoft-Exchange-Diagnostics: 1; MWHPR03MB3328; 3:YYkfslqSG5D4oS7pI2m8NaWT+hJbqVgVHiy20vW52CMZTo2Fdb2et/nnA13z3FcNorKFvIdfTBykXatkov+E0RdrVKuBRzeXTmRuE2zVT28b0a8UFF0/PmOwNdvBd6bWD7HTrWYfFX9bfbZJO6gUWC/flYAEYUWG7WLJCuMjFRzBkdI3fWlgpOYF3uXftdc4o7VYacg8p6ZGf3uFmZ+Mm4LPqaJ6GL0jeHkYhC2TMR5vSYcHv18RDl6700FWiW7H/cCGnp9KIq4mgbAYms411MxkfXakZSkfpvRn0S53hY589xkw/6HMkWjojYcm/+tr4Fq04x06+lnv6wKqo26/hLwn8BS+qyWyFgjN4ozIxPk=; 25:dA0g1y9CywKKffNoSaBznIAyFb/6+wdMBZDvCCc2p8evLML4ZhfHBcCJvsB8f9STJ86aZlnMvKMo/NH/HqX4c/JdCFkrUCzt13en38HS/X/0D5ZFSOjFo/9u1K7AnemCNik1TftubsnB18DTVlhj6+4AEZyX+TeLYg7qUTnmCq+2u8pNlW1p53zfbOZYQ7+RTA4pyvY7rHrjrDiiEXP9LZz+HAyBvpc2veDWq7sN0F3O4jncsEp4EmnD5eS/zijloIKES0XOoGSc+LOFSQejjrbIc07/oxY6KK2gwbQLiFji+RtnTcqlJDluv8Vy4q8KNrD5rpFICVXH+tOIUls2oA== X-MS-TrafficTypeDiagnostic: MWHPR03MB3328: X-Microsoft-Exchange-Diagnostics: 1; MWHPR03MB3328; 31:4QkMfxPFnoLpwJ+G/Z8OFoksRNNOKyEFe8bD1qIeukxPMuAfb1FT1ohfar41tS71+vPRMlZWjFvCMCHQjYet/GkejShJjsHp3O7t9TVFpRVM6LNXVQ19yU/kAWnls4vtpsvtQWlp4BtfzQAWisirKz+kKkf+mKBgOwTOto5M/ESDrYtyuDZqo3S7pniAcAKzb/Z8m5D8B661og+FNlLUI039JIF5vJgydPOFyieEdAs=; 4:2pqXKyMQtprrN8QT7l3bqtSfYHLFEO1HOloSvSqvHPT5akeee3MW50i3P4bCygAQI+20gXsedz7ESEI4vPYHmftXqSDbq1hHAbd2SykeBwoD5fFORgYWRQ/yVcSAUf51kBFjrh7iscqi5ccDHH74Lqn1QxVqLzlMSmwiXnoty+mHmPO1IabCn6tnT24G80yt9h6wObO9fYuW9PA/ndaemtk8OaDDi9UWRmPnlj+iJRaPQ5NbgpEmH5U9fMdtgcyB+39lnEQDb6CK5D26cl2AYkmIBugMCtMkTBD/0ASqB/dtLECuBPmhqcuEv/lkbEVsp8WfTbKuH33g11fEubqTPw== X-Exchange-Antispam-Report-Test: UriScan:(185117386973197)(228905959029699); X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6095135)(2401047)(8121501046)(5005006)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(3002001)(6055026)(6096035)(20161123559100)(20161123561025)(20161123563025)(20161123556025)(201703131430075)(201703131448075)(201703131433075)(201703161259150)(201703151042153)(20161123565025)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR03MB3328; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(400006)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR03MB3328; X-Forefront-PRVS: 04270EF89C X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtNV0hQUjAzTUIzMzI4OzIzOko0UjIrWlZFamh1K1hXYmtqNVhka3JuR1VX?= =?utf-8?B?Ykx0MFcrRFEvdlUxSVdBR0FjQnp4MGN5VjB1SmdKSnloakhYTUk4c25wTzhX?= =?utf-8?B?U3QzRTJzeHdQZy8ralNqL2dadzZoWnFNSlpqZnRHUC9JWllzc0NnQTN0QmFi?= =?utf-8?B?dS9CK29uVnF2cUM0WFdlNzdzVW9vRGtWN0ZFM0RVa0I0WEJHOVE1ckNtblIx?= =?utf-8?B?clFHbXV3Qi9TaEtHWVhXYUNTb0l5bnBGajNETHkyMEhaR1YwWlRzMjhRakI0?= =?utf-8?B?TXFNb041aW5aOTVIcVlJUUt4MmlsV2U5S3FvYm14Z2Rvck45RHJyTVpqMmo2?= =?utf-8?B?Nms3aVUrMEVkbXk4TVdHUkxoVmIxYk5PUHk2UkpLd0V1ZWwzSDdnY3M1bU1D?= =?utf-8?B?RHpYNG1RS1VYb2NpcUtPT2xIaFZMOCtnS0FKWE9SazJYcm9iekV1MDdWWFZw?= =?utf-8?B?THVTeExWeTBjWGR2Vk5nejJGbXNPT2Y0MGJveFlrYmlZRUVCWjdnc0tRS0Iz?= =?utf-8?B?ZkNWNVRMS1ZxbU9ZYzFhcEZjVTczTjU3TG9sN1JZdnhuZDE4OC9ZOEVaUVUy?= =?utf-8?B?RTR1c2ZjQzdiZ1B5VnNWYkZYRGp1WGFQVkhtNWhVZlFkUmJXenhOSjdwdnVl?= =?utf-8?B?S0RNY3N4TWQ3eGd3L2M5c2pFWUVXZnNVdXdER0RoVTh6UlFuTS9wWS9POWV6?= =?utf-8?B?Q1pzWFl5RS9HNHNOMmxZM1lNeHkzMUJ2QnBzdlhuMzQ0TWRBc0k0anRDV3V5?= =?utf-8?B?a0g3UTd2Tm03VHRUc0JucXkzRFlKK09ZYllheExLczljczYrRW55Wk92Vmpq?= =?utf-8?B?aWlMbVZZSGJMM0o0dEpPK2Y3MkNwSGhRM1R5bU02V2paN1Erc0dvc0VWUDZO?= =?utf-8?B?TVA3b0xHYVczY0l4ODVPbmk5SjJ0Z0dKNVd0YWpYejJtVFJLYnUvWVIxVU5s?= =?utf-8?B?a2p0SWZXcE1vOXBJR1JIcHRiUU5QNFNwcTNQaVdSU1l4NjgwdTZnSTdmck14?= =?utf-8?B?MXNNYWlvQVB2NE5PamNsb0pqVkgyZlNXL3loZkpxSktQQ0xuWDMyR2ZXcnRz?= =?utf-8?B?U2s0WEVwaUFZZm5HbXVGR3hpbkhQdXc0dTBMUjhWdXJRSjMvdk5uRjlFdkJX?= =?utf-8?B?MVYwYTZFbGE0eHdSY1lYSStzMGZydW1XQ01iYW1OVldiV3I0Q1NmZGtxVWht?= =?utf-8?B?OS9MY2h5YmQwTTAzRitVc1M3alBHc0RLalVkbEp1dyt6SVl4QTJnTWRVTVpF?= =?utf-8?B?bHlCWGF2ME54V0xxZm0zd2x0K2JuVi8wUDBSMCtuUUMrTlZtNUlUOWd5ZjJW?= =?utf-8?B?S2NXdm4xUjNocFJ1UVFPM0ZPaUYxS2wyMndaNXZCNEtSdFp3TCt3OVY4REta?= =?utf-8?B?YWY2NlhqczFPUFR2Mm9lME5FdG9lQmRVV3RMbkVJQ3g4TXhLaXpZd1NVaWFP?= =?utf-8?B?QVd1MngvUCttd3RrM3Fpa3QzdGFlSU10Wm10YmhNcHNjaE1kZURnVWx1cW5T?= =?utf-8?B?V2xuK0lrUGtUWUlEZ3dYejNIUS93RHYrQmZsVmMwZjB6YzJuNFdvcm84ekNV?= =?utf-8?B?TVA0SmFGUFhWNmhzUVAzNFlFNDBJSHpnTU1OaVp0MXpYQUFVNjQwU2JpdUlw?= =?utf-8?B?cFF6Y1pWOFRMSFVsb1M3WEFiMzhGVDhMUFJGT2VLQ0JOMUJRZ21ydCtIUnhM?= =?utf-8?B?bjg5SGFXNWJWUkREbGtROFRQNkFBY3l4MFBqVnNTeWNJbzM2ZzNkK1djdkZ6?= =?utf-8?B?UDBTZzgwUUZVbjFHOTcvZy8yekRsTkphbUJrbDFVaHErdUtGWllLcWIwWE54?= =?utf-8?B?TXdsMDhNbnVUaVlSU0tsMzZzc3dVRzhrMTByQXdid1hIajNqaEtTS01FOTc2?= =?utf-8?B?Ym1xWW9ueVh1SFlZMER2MzlrUkRGcTduamV5V1FxQWtKVWpiaHlTUk1SajM1?= =?utf-8?B?ZHFBN2taT25BPT0=?= X-Microsoft-Exchange-Diagnostics: 1; MWHPR03MB3328; 6:kO35zrP/D/Ra8SGfCWfDGFp3Nkb8yChVdeErVNT3P/6Df3/iXqWBkBlEkmm6mbiUvtUXxVlta04qcgNlot/IM9bqRXLuU8vmBULYyQrd+9slZk4m3bIqoFNYdOsgBX4/UMFuGvemcsXOQUNU3R8k4m/ERbikzYWX99bZR5Z4Pjtj5fMlWHwixyHUB19GaDpE58Ve7VLO8/YsZJiQg850tKbBcLMdkh6Q2D3BiEeVY4P3iBTTMaLZtfQz1taY2YYy9VTUexYVGQp56fCNPaV/Oy+yAH59Agi+SqLAUVWLpEjN5T5l501klLzJz5zxh8qvV2Nmb7ow9ktMqHN0wqDRfw==; 5:S6jYbwcGlXQXjzMYq8JnFdyvL09lKY810N7rw3WUYB1YSbCnaxh/SEfhg89rJHOPBOYveX3oiJS7/72PtCPtJGe/dqAUeghFiwuhSDQuKXZWlmwJh3CFsixF172b6SO8m1h7Pput0akI7Otz/ci0tw==; 24:9WX8SSRjTi391Nj6rZo6O6RiAdZTAb9513R5DniMpyhTLw9Qd0UWbqE9rtWH0S3lBhXYpLqPdqK3/qBtYbEnNNywew270JjQCUhxoPX4tAI=; 7:eXPU3/ojBqyqugqsCxr8zCRy1JluQh+KHKBUEOJNmujytHpfjOaxew2AvSLvYcDoDBpuAbvqf/FkYmHGfKmiWTshF7rV+5cpqWIttY1Vb6Wn00p2GdXwdAVpczF6HqjspVXF3Ly4JX8PvucK4tOMhwIJl3OELL1diIERYnefv48RsrFI7ELA9ojBApd+Ul6n1Gfd+yIF/W8sIdgK1k+5rggp4RJV9YVzrbdYgu8Kg0o= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Sep 2017 12:59:44.1245 (UTC) X-MS-Exchange-CrossTenant-Id: 5afe0b00-7697-4969-b663-5eab37d5f47e X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=5afe0b00-7697-4969-b663-5eab37d5f47e; Ip=[192.88.168.50]; Helo=[tx30smr01.am.freescale.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR03MB3328 Subject: Re: [dpdk-dev] [PATCH 6/6] app/crypto-perf: use single mempool 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: Mon, 11 Sep 2017 12:59:46 -0000 Hello Pablo, I have a comment inline: On Monday 11 September 2017 04:38 PM, De Lara Guarch, Pablo wrote: >> -----Original Message----- >> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Akhil Goyal >> Sent: Wednesday, August 30, 2017 9:31 AM >> To: De Lara Guarch, Pablo ; Doherty, >> Declan ; Trahe, Fiona >> ; Jain, Deepak K ; >> Griffin, John ; >> jerin.jacob@caviumnetworks.com; hemant.agrawal@nxp.com >> Cc: dev@dpdk.org >> Subject: Re: [dpdk-dev] [PATCH 6/6] app/crypto-perf: use single >> mempool >> >> Hi Pablo, >> On 8/18/2017 1:35 PM, Pablo de Lara wrote: >>> In order to improve memory utilization, a single mempool is created, >>> containing the crypto operation and mbufs (one if operation is >>> in-place, two if out-of-place). >>> This way, a single object is allocated and freed per operation, >>> reducing the amount of memory in cache, which improves scalability. >>> >>> Signed-off-by: Pablo de Lara >>> --- >>> app/test-crypto-perf/cperf_ops.c | 96 ++++++-- >>> app/test-crypto-perf/cperf_ops.h | 2 +- >>> app/test-crypto-perf/cperf_test_latency.c | 350 ++++++++++++------- > --- >> ---- >>> app/test-crypto-perf/cperf_test_throughput.c | 347 >>> ++++++++++++------ >> -------- >>> app/test-crypto-perf/cperf_test_verify.c | 356 ++++++++++++-------- > --- >> ---- >>> 5 files changed, 553 insertions(+), 598 deletions(-) >>> >> NACK. >> This patch replaces rte_pktmbuf_pool_create with the >> rte_mempool_create for mbufs, which is not a preferred way to allocate > memory for pktmbuf. >> >> Any example/test application in DPDK should not be using this, as this >> kind of usages will not be compatible for all dpdk drivers in general. >> >> This kind of usages of rte_mempool_create will not work for any >> devices using hw offloaded memory pools for pktmbuf. >> one such example is dpaa2. > > Hi Akhil, > > Sorry for the delay on this reply and thanks for the review. > > I think, since we are not getting the buffers from the NIC, but we are allocating > them ourselves, it is not strictly required to call rte_pktmbuf_pool_create. > In the end, we only need them for memory for the crypto PMDs and we are not touching > anything in them, so I think using calling rte_mempool_create should work ok. > Having a single mempool would be way more performant and would avoid the scalability > issues that we are having in this application now, and knowing that this application > was created to test crypto PMD performance, I think it is worth trying this out. > > What is it exactly needed for dpaa2? Is the mempool handler? If I recall correctly: This is the call flow when rte_pktmbuf_pool_create is called: - rte_pktmbuf_pool_create `-> rte_mempool_create_empty `-> allocate and fill mempool object with defaults `-> rte_mempool_set_ops_byname `-> sets mempool handler to RTE_MBUF_DEFAULT_MEMPOOL_OPS `-> rte_mempool_populate_default `-> calls pool handler specific enqueue/dequeue but that of rte_mempool_create is: - rte_mempool_create `-> rte_mempool_create_empty `-> allocate and fill mempool object with defaults `-> rte_mempool_set_ops_byname `-> set to one of ring_*_* No check/logic for configuration defined handler like RTE_MBUF_DEFAULT_MEMPOOL_OPS `-> rte_mempool_populate_default `-> calls ring* handler specific enqueue/dequeue Calling rte_mempool_create bypasses the check for any mempool handler configured through the build system. > Would it work for you if I create the mempool in a similar way as what > rte_pktmbuf_pool_create is doing? Calling rte_mempool_set_ops_byname? Yes, but that would mean using the combination of rte_mempool_create_empty and rte_mempool_set_ops_byname which, eventually, would be equal to using rte_pktmbuf_pool_create. rte_mempool_set_ops_byname over a mempool created by rte_mempool_create would mean changing the enqueue/dequeue operations *after* the mempool has been populated. That would be incorrect. I am not sure of what the intent it - whether these buffers should be allowed to be offloaded to hardware. If yes, then rte_mempool_create wouldn't help. > > Thanks! > Pablo > > >> >> -Akhil