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 86EE4A0518; Tue, 11 Aug 2020 23:15:04 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 5ECC41C023; Tue, 11 Aug 2020 23:15:04 +0200 (CEST) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id 73E1B1C022 for ; Tue, 11 Aug 2020 23:15:02 +0200 (CEST) IronPort-SDR: IklkPfR0KrCbPRyl1YY4riOswixc5ZckoeabjqOviLyrWAddr2RF9L5POiHS2WvN7+1La0dK6Z KWHkowSvSfjQ== X-IronPort-AV: E=McAfee;i="6000,8403,9710"; a="151506837" X-IronPort-AV: E=Sophos;i="5.76,301,1592895600"; d="scan'208";a="151506837" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Aug 2020 14:15:01 -0700 IronPort-SDR: zWdg3SsI6SAvZXm07NLyYRU7O2oM0+TladbZqZ+XO2qBz9dHdG8Dt/KXalU2EIbIWqVRkIbORz 0rS+9o2MFPJg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.76,301,1592895600"; d="scan'208";a="369069200" Received: from orsmsx603-2.jf.intel.com (HELO ORSMSX603.amr.corp.intel.com) ([10.22.229.83]) by orsmga001.jf.intel.com with ESMTP; 11 Aug 2020 14:15:01 -0700 Received: from orsmsx611.amr.corp.intel.com (10.22.229.24) by ORSMSX603.amr.corp.intel.com (10.22.229.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Tue, 11 Aug 2020 14:15:00 -0700 Received: from ORSEDG001.ED.cps.intel.com (10.7.248.4) by orsmsx611.amr.corp.intel.com (10.22.229.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.1713.5 via Frontend Transport; Tue, 11 Aug 2020 14:15:00 -0700 Received: from NAM02-SN1-obe.outbound.protection.outlook.com (104.47.36.53) by edgegateway.intel.com (134.134.137.100) with Microsoft SMTP Server (TLS) id 14.3.439.0; Tue, 11 Aug 2020 14:15:00 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TiimY/RCLzRfS+FXWzryoVcgNXCl0IOCK9m0GJudc9aKGyaNvJSDO8bAzhWOVBpjIGVtUuLkXTtgIgZwFxZ87cBFwjmUmLOwfHZ66sR7xUCRgxSz3/2sM80MkdH5LYNOfLiIYKSXmyeuyy+v84X2t7zqeJFKNYeXNoeOWlIEehhbrn5rzylqMobatlbNHsSl7RM3EoCnZTg7yyFknsATtvt8wJgBzaTVq380cOKMzzcA7DfABjTYCHiiFGxzXnA+xkqNnWXT34Z9yhf7F7WfVkU9Xg5IPCEuIe6IbvkhNoC10rKWnfZzIvXkhjAlnReNaQ0n6g4ciHojUxcZPbKaHQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=q8sRuN9f+BvchKubJ0EBgONONXNIKBIOpbptsEfKY3U=; b=n72GNkp1kqdiS6BXwq6t0P2OOu+LdvisrYdTiOYUMhEJHCZJ17E3QblyjIIPpK5+1us6y+El8/khxukQK/D7D6JplPmQf2Wr0Jag0B4b3uGKQuLLOHjVc27V73rc8TKrsu1xceq7DqJM/Bg0e0U7kltGMWrElgn2k/HX8I+pvr6DKpmncxkTUwRr/ZBiKkWXcZbiMTSuwS8XuqOEoWJHqNMXsTExDb9oARaNxpMtHN3TgXsaMkorGU3qklZoD/m6vwaEGK/T42Jx1gYW9h+WEeb0bS4p2U3UEe1sXmJufAqhoDY9XWGFe9RRGiNnLSZO6hWfVoe67EVYpTIHlso26Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel.onmicrosoft.com; s=selector2-intel-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=q8sRuN9f+BvchKubJ0EBgONONXNIKBIOpbptsEfKY3U=; b=MY2HxwTZPFcQCAnBFMXBCiXRt5SurSLMhDGulb8ngkj373QzIekASor1WctUS7ERfLk4kB9r+3ZXcH5I5YnGzUl2dPlTogZrVZZvV6v6ajfUmFtggj/QfAQ4bJyxF7Y5F+nVdrtqtd0jW61MYRqeq+26E2KybuWwsBSPEK0Acmc= Received: from SN6PR11MB2574.namprd11.prod.outlook.com (2603:10b6:805:59::14) by SN6PR11MB3021.namprd11.prod.outlook.com (2603:10b6:805:d1::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3261.17; Tue, 11 Aug 2020 21:14:59 +0000 Received: from SN6PR11MB2574.namprd11.prod.outlook.com ([fe80::54:b143:c75e:41bd]) by SN6PR11MB2574.namprd11.prod.outlook.com ([fe80::54:b143:c75e:41bd%7]) with mapi id 15.20.3261.025; Tue, 11 Aug 2020 21:14:59 +0000 From: "Eads, Gage" To: Honnappa Nagarahalli , Stephen Hemminger CC: Steven Lariau , Olivier Matz , "dev@dpdk.org" , Dharmik Thakkar , nd , nd Thread-Topic: [dpdk-dev] [PATCH 1/4] test/stack: avoid trivial memory allocations Thread-Index: AQHWa0FByAdNTBStI0ek3KNmWSaOx6kzWGDQgAAP/QCAAAMJAIAABpBQ Date: Tue, 11 Aug 2020 21:14:58 +0000 Message-ID: References: <20200805155721.19808-1-steven.lariau@arm.com> <20200805155721.19808-2-steven.lariau@arm.com> <20200811133858.04ec8369@hermes.lan> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-version: 11.5.1.3 dlp-product: dlpe-windows dlp-reaction: no-action authentication-results: arm.com; dkim=none (message not signed) header.d=none;arm.com; dmarc=none action=none header.from=intel.com; x-originating-ip: [68.203.30.51] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b3572c0e-eb9a-46fe-905b-08d83e3b9aa4 x-ms-traffictypediagnostic: SN6PR11MB3021: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:883; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: z5nKAbYmut9MU3VxpeoZ90I1TzX5rKzmb1k4cbiKvOULvkrjRqmw4emYB87+F5c7/ie4BOQxoQvnKSCfcILaEDvOPt9AOB7hD/WIq0+TWfulXGQ4DjiT017od5C0CqQDOfnYd+sUIaAb5F7EHRIos4ouOH60ySr1euLj8+mbDkWwcZcIJXxRlObTAzYsSsp1fz2KvtXoe4Qjn+jvD9bFKPFsCWAkTxsOq75ofxe/z0AUh+YNXRZ1zbUQjOJwfj1+ksuL/mFpaHMcSFo8PK8O+cgoQR2hpseOtnGhwxjZmlvXPXRYbQ41HbuUH0gko9wA x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SN6PR11MB2574.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(346002)(396003)(366004)(376002)(136003)(39860400002)(52536014)(9686003)(478600001)(53546011)(76116006)(33656002)(86362001)(8936002)(6506007)(66556008)(66446008)(8676002)(66476007)(7696005)(64756008)(186003)(55016002)(2906002)(66946007)(5660300002)(71200400001)(83380400001)(4326008)(54906003)(110136005)(316002)(26005); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: fQe8I5KjefCkcdBgWn/lpgNQ5aokXyWhViKbMcG45rToHiepZEh/o7ukCwzqoZ9e/zFhxe/2kHOO6ob69XgyKYrhWDR54t/KHqQdcJ4j0pv7Nn0oPlaJJuy8gzHv6gWtu3PUyOrYmtXdN77hLf+964T9Vgetw8S7u/y8fWNN92sxibZpzHdyKZFdFT76/4maCaJvrQwJxq7BqHqhgLTK5iyob8LbWrtwkJiuvY3kDOgVDv2j5gUfbJgeSymQHvTz9vVrIdYNX90vqq/R/cCpzSxnsE2TCqgjLJsCpQQC3g/kV4YeXnCxzM3pniQhFuwjC0+hHr22WTqV8d8ehPe2IHxh0xkN+GhvivKHOFCIrBvnV1x9TanctL/ynnHWN1h9g+aF6vF6s34RPPxb2ulZh7eczISKufp670A4Ot7iy/u7M0ud/s9LJanbv2cEqWWhvCBKihvYmhlW/9q8X+IDJZSGQYA0TmqiyeOHDJ8+wSCCx1ZzLxn6Q05u4Fs/O/HPb9qStYftsg5iy3pzNb2/2PgQGywjwYx4gjpSJ40rMJs2Aidk1/OR61ZK75x8staaClLrK4HPHSY3Z0kQN7aH2BJdNZszkpWvz96hrHcasXZVmA+7TXvdQX3LT4jAzFNQ1/6jtAvt6WIW2q9WvXQPBw== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SN6PR11MB2574.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: b3572c0e-eb9a-46fe-905b-08d83e3b9aa4 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Aug 2020 21:14:58.9744 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 9XSVPACajTqnLO/YuGXkQxJIhZIN9db/AGw8/rQSRY/Tmfy05s67fIyRFloZNc/PJqbrwa0ibKp9NO1i293EqA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR11MB3021 X-OriginatorOrg: intel.com Subject: Re: [dpdk-dev] [PATCH 1/4] test/stack: avoid trivial memory allocations 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" > -----Original Message----- > From: Honnappa Nagarahalli > Sent: Tuesday, August 11, 2020 3:50 PM > To: Stephen Hemminger ; Eads, Gage > > Cc: Steven Lariau ; Olivier Matz > ; dev@dpdk.org; Dharmik Thakkar > ; nd ; Honnappa Nagarahalli > ; nd > Subject: RE: [dpdk-dev] [PATCH 1/4] test/stack: avoid trivial memory > allocations >=20 > >=20 > > > > > > > > Replace the arguments array by one argument. > > > > All objects in the args array have the same values, so there is no > > > > need to use an array, only one struct is enough. > > > > The args object is a lot smaller, and the allocation can be replace= d > > > > with a stack variable. > > > > > > > > The allocation of obj_table isn't needed either, because MAX_BULK i= s > > > > small. The allocation can instead be replaced with a static array. > > > > > > > > Signed-off-by: Steven Lariau > > > > Reviewed-by: Dharmik Thakkar > > > > Reviewed-by: Phil Yang > > > > Reviewed-by: Ruifeng Wang > > > > --- > > > > app/test/test_stack.c | 39 ++++++--------------------------------- > > > > 1 file changed, 6 insertions(+), 33 deletions(-) > > > > > > > > diff --git a/app/test/test_stack.c b/app/test/test_stack.c index > > > > c8dac1f55..5a7273a7d 100644 > > > > --- a/app/test/test_stack.c > > > > +++ b/app/test/test_stack.c > > > > @@ -280,16 +280,9 @@ static int > > > > stack_thread_push_pop(void *args) > > > > { > > > > struct test_args *t =3D args; > > > > - void **obj_table; > > > > + void *obj_table[MAX_BULK]; > > > > int i; > > > > > > > > - obj_table =3D rte_calloc(NULL, STACK_SIZE, sizeof(void *), 0); > > > > - if (obj_table =3D=3D NULL) { > > > > - printf("[%s():%u] failed to calloc %zu bytes\n", > > > > - __func__, __LINE__, STACK_SIZE * sizeof(void *)); > > > > - return -1; > > > > - } > > > > - > > > > for (i =3D 0; i < NUM_ITERS_PER_THREAD; i++) { > > > > unsigned int success, num; > > > > > > > > @@ -310,28 +303,25 @@ stack_thread_push_pop(void *args) > > > > if (rte_stack_push(t->s, obj_table, num) !=3D num) { > > > > printf("[%s():%u] Failed to push %u pointers\n", > > > > __func__, __LINE__, num); > > > > - rte_free(obj_table); > > > > return -1; > > > > } > > > > > > > > if (rte_stack_pop(t->s, obj_table, num) !=3D num) { > > > > printf("[%s():%u] Failed to pop %u pointers\n", > > > > __func__, __LINE__, num); > > > > - rte_free(obj_table); > > > > return -1; > > > > } > > > > > > > > rte_atomic64_sub(t->sz, num); > > > > } > > > > > > > > - rte_free(obj_table); > > > > return 0; > > > > } > > > > > > Agreed, the dynamic allocation is unnecessary. > > > > > > > > > > > static int > > > > test_stack_multithreaded(uint32_t flags) { > > > > - struct test_args *args; > > > > + struct test_args args; > > > > unsigned int lcore_id; > > > > struct rte_stack *s; > > > > rte_atomic64_t size; > > > > @@ -344,45 +334,28 @@ test_stack_multithreaded(uint32_t flags) > > > > printf("[%s():%u] Running with %u lcores\n", > > > > __func__, __LINE__, rte_lcore_count()); > > > > > > > > - args =3D rte_malloc(NULL, sizeof(struct test_args) * RTE_MAX_LCOR= E, > > > > 0); > > > > - if (args =3D=3D NULL) { > > > > - printf("[%s():%u] failed to malloc %zu bytes\n", > > > > - __func__, __LINE__, > > > > - sizeof(struct test_args) * RTE_MAX_LCORE); > > > > - return -1; > > > > - } > > > > - > > > > s =3D rte_stack_create("test", STACK_SIZE, rte_socket_id(), flags= ); > > > > if (s =3D=3D NULL) { > > > > printf("[%s():%u] Failed to create a stack\n", > > > > __func__, __LINE__); > > > > - rte_free(args); > > > > return -1; > > > > } > > > > > > > > rte_atomic64_init(&size); > > > > + args.s =3D s; > > > > + args.sz =3D &size; > > > > > > > > RTE_LCORE_FOREACH_SLAVE(lcore_id) { > > > > - args[lcore_id].s =3D s; > > > > - args[lcore_id].sz =3D &size; > > > > - > > > > if (rte_eal_remote_launch(stack_thread_push_pop, > > > > - &args[lcore_id], lcore_id)) > > > > + &args, lcore_id)) > > > > rte_panic("Failed to launch lcore %d\n", lcore_id); > > > > } > > > > > > > > > In general we shouldn't pass a stack variable to other threads. Thoug= h > > > your code here looks fine, I'd rather err on the safe side in case > > > this is ever used as a template/basis for some other > > > code...particularly since there's no performance/correctness/etc. > penalty to > > using dynamically allocated memory. > > > > > > To support patch 2/4, you can instead convert the rte_malloc to > > > allocate a single shared test_args structure. Or perhaps move patch 4 > > > earlier in the series, and simply pass the stack pointer instead. > > > > > > Thanks, > > > Gage > > > > There is no gain to using rte_malloc unless you are doing > primary/secondary > > process or trying to test rte_malloc. Why not use regular malloc which = has > > good tools and library support. >=20 > I think making 'args' a global variable is enough in this case. Agreed. Thanks, Gage