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 14646A04B8; Tue, 5 May 2020 17:01:41 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 9E5061D614; Tue, 5 May 2020 17:01:39 +0200 (CEST) Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id 884C31D5F8 for ; Tue, 5 May 2020 17:01:37 +0200 (CEST) IronPort-SDR: e9pHhmg+oMlRYJ5FMz4YrZR8Ih0Dr0ivPpCw33n7uQ+s6993P7Vcv0/VqlEP0EfesaOnJ0JDGs U6RRQCgCgHLA== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 05 May 2020 08:01:36 -0700 IronPort-SDR: +JkwgQ7yXWzU9dwszYUEt+ZcTzvBbNYbMcGkVFNg4w8nPORlthmQPHWKO0VNzfK4bqukJD6AVY 32ZD9c0KW4TQ== X-IronPort-AV: E=Sophos;i="5.73,355,1583222400"; d="scan'208";a="434516677" Received: from bricha3-mobl.ger.corp.intel.com ([10.252.57.186]) by orsmga005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA; 05 May 2020 08:01:34 -0700 Date: Tue, 5 May 2020 16:01:31 +0100 From: Bruce Richardson To: Anatoly Burakov Cc: dev@dpdk.org Message-ID: <20200505150131.GA1437@bricha3-MOBL.ger.corp.intel.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [dpdk-dev] [RFC] mem: add atomic lookup-and-reserve/free memzone API 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" On Tue, May 05, 2020 at 02:24:07PM +0000, Anatoly Burakov wrote: > Currently, in order to perform a memzone lookup and create/free > the memzone, the user has to call two API's, creating a race > condition. This is particularly destructive for memzone_free call > because the reference provided to memzone_free at the time of call > may be stale or refer to a different memzone altogether. > > Fix this race condition by adding an API to perform lookup and > create/free memzone in one go. > > Signed-off-by: Anatoly Burakov > --- > lib/librte_eal/common/eal_common_memzone.c | 125 ++++++++--- > lib/librte_eal/include/rte_memzone.h | 235 +++++++++++++++++++++ > lib/librte_eal/rte_eal_version.map | 4 + > 3 files changed, 340 insertions(+), 24 deletions(-) > While I agree that there is a race, is this really a problem in the real world? Do we really need to expand the number of APIs for allocating memory further? If we really do need the ability to do lookup and create in one, rather than adding new APIs can we not just add another flag to the existing rte_memzone_reserve call?