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 F29BFA034F; Wed, 6 May 2020 11:35:19 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 45C261D70E; Wed, 6 May 2020 11:35:19 +0200 (CEST) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id 1E7DB1D70B for ; Wed, 6 May 2020 11:35:15 +0200 (CEST) IronPort-SDR: LSvecZKQxKA5SfRamb/1+3763zsNE3URarduIGbr5Ozeo84ALZk0YqH74xgN6CMgihypn0rJrC wsUzlZ5Nh5Cw== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 May 2020 02:35:13 -0700 IronPort-SDR: vxToQ9uLw9R+CBUT99sYH1GD0cyJ2tJeT4CVzkgL+G4d7SVaKg0yuiLXS9Pbp1DH6mG47dtdy1 KskeS9UqZ5dQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.73,358,1583222400"; d="scan'208";a="278171688" Received: from aburakov-mobl.ger.corp.intel.com (HELO [10.209.121.37]) ([10.209.121.37]) by orsmga002.jf.intel.com with ESMTP; 06 May 2020 02:35:12 -0700 To: Bruce Richardson Cc: dev@dpdk.org References: <20200505150131.GA1437@bricha3-MOBL.ger.corp.intel.com> From: "Burakov, Anatoly" Message-ID: <0ca5b4e6-7a8b-1044-02df-9e5b0f3600b7@intel.com> Date: Wed, 6 May 2020 10:35:10 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <20200505150131.GA1437@bricha3-MOBL.ger.corp.intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit 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 05-May-20 4:01 PM, Bruce Richardson wrote: > 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? > I'm not sure how much of a problem it is, hence why this is an RFC rather than a full blown patch :) as in, "i've identified a race, do we care?" kind of proposition. > 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? > That's a good idea for memzone_reserve(), but it wouldn't work for memzone_free(). -- Thanks, Anatoly