From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id CDEF71BB5A for ; Thu, 21 Jun 2018 10:51:25 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Jun 2018 01:51:24 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.51,251,1526367600"; d="scan'208";a="66007025" Received: from aburakov-mobl.ger.corp.intel.com (HELO [10.252.4.182]) ([10.252.4.182]) by fmsmga001.fm.intel.com with ESMTP; 21 Jun 2018 01:51:22 -0700 To: Qi Zhang , thomas@monjalon.net Cc: konstantin.ananyev@intel.com, dev@dpdk.org, bruce.richardson@intel.com, ferruh.yigit@intel.com, benjamin.h.shelton@intel.com, narender.vangati@intel.com References: <20180607123849.14439-1-qi.z.zhang@intel.com> <20180621020059.1198-1-qi.z.zhang@intel.com> <20180621020059.1198-6-qi.z.zhang@intel.com> From: "Burakov, Anatoly" Message-ID: <8a605b98-265e-08ca-0d5b-7f0d40a73ca4@intel.com> Date: Thu, 21 Jun 2018 09:51:22 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <20180621020059.1198-6-qi.z.zhang@intel.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Subject: Re: [dpdk-dev] [PATCH v2 05/22] ethdev: introduce device lock 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: Thu, 21 Jun 2018 08:51:26 -0000 On 21-Jun-18 3:00 AM, Qi Zhang wrote: > Introduce API rte_eth_dev_lock and rte_eth_dev_unlock to let > application lock or unlock on specific ethdev, a locked device > can't be detached, this help application to prevent unexpected > device detaching, especially in multi-process environment. > > Also introduce the new API rte_eth_dev_lock_with_callback and > rte_eth_dev_unlock_with callback to let application to register > a callback function which will be invoked before a device is going > to be detached, the return value of the function will decide if > device will continue be detached or not, this support application > to do condition check at runtime. > > Signed-off-by: Qi Zhang > --- > + > +static int clean_lock_callback_one(uint16_t port_id) > +{ > + struct lock_entry *le; > + int ret = 0; > + > + rte_spinlock_lock(&lock_entry_lock); > + > + TAILQ_FOREACH(le, &lock_entry_list, next) { > + if (le->port_id == port_id) > + break; > + } > + > + if (le != NULL) { > + le->ref_count--; > + if (le->ref_count == 0) { > + TAILQ_REMOVE(&lock_entry_list, le, next); > + free(le); > + } > + } else { > + ret = -ENOENT; > + } > + > + rte_spinlock_unlock(&lock_entry_lock); > + return ret; > + > +} > + > +void clean_lock_callback(uint16_t port_id) > +{ > + int ret; > + > + for (;;) { > + ret = clean_lock_callback_one(port_id); > + if (ret == -ENOENT) > + break; > + } > +} Why not lock/unlock the list in clean_lock_callback() and proceed to cleaning callbacks one by one, instead of locking-and-unlocking the list over and over again? -- Thanks, Anatoly