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 542E0A04BC; Fri, 9 Oct 2020 18:57:02 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 063471BC9C; Fri, 9 Oct 2020 18:56:59 +0200 (CEST) Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by dpdk.org (Postfix) with ESMTP id 54D781BACD for ; Fri, 9 Oct 2020 18:56:57 +0200 (CEST) IronPort-SDR: q6SEUtAUO0CKvtb28HoMCOAF+12TAFWRbtnNo11PM0kM7a4MiboZyUgTBq0n0/UvBm+CojEZAR BVYGSgAkMTQw== X-IronPort-AV: E=McAfee;i="6000,8403,9769"; a="162872402" X-IronPort-AV: E=Sophos;i="5.77,355,1596524400"; d="scan'208";a="162872402" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Oct 2020 09:56:51 -0700 IronPort-SDR: AIECM/sDrmz5NQh2+ep7vmUZoKAl1TQu7kEtpuyMCzICWND8MRzRm1kRSQADS9gGNYT4j18i3i 10HKtolxoG4g== X-IronPort-AV: E=Sophos;i="5.77,355,1596524400"; d="scan'208";a="462254401" Received: from aburakov-mobl.ger.corp.intel.com (HELO [10.213.3.170]) ([10.213.3.170]) by orsmga004-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 09 Oct 2020 09:56:49 -0700 To: "Ananyev, Konstantin" , "Ma, Liang J" , "dev@dpdk.org" Cc: "Hunt, David" , "stephen@networkplumber.org" References: <1599214740-3927-1-git-send-email-liang.j.ma@intel.com> <1601647919-25312-1-git-send-email-liang.j.ma@intel.com> <1601647919-25312-4-git-send-email-liang.j.ma@intel.com> From: "Burakov, Anatoly" Message-ID: Date: Fri, 9 Oct 2020 17:56:46 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.12.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 Subject: Re: [dpdk-dev] [PATCH v4 04/10] power: add simple power management API and callback 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 09-Oct-20 5:51 PM, Ananyev, Konstantin wrote: >>> >>>> +case RTE_POWER_MGMT_TYPE_PAUSE: >>>> +rte_eth_remove_rx_callback(port_id, queue_id, >>>> + queue_cfg->cur_cb); >>>> +break; >>>> +case RTE_POWER_MGMT_TYPE_SCALE: >>>> +rte_power_freq_max(lcore_id); >>>> +rte_eth_remove_rx_callback(port_id, queue_id, >>>> + queue_cfg->cur_cb); >>>> +rte_power_exit(lcore_id); >>>> +break; >>>> +} >>>> +/* it's not recommend to free callback instance here. >>>> + * it cause memory leak which is a known issue. >>>> + */ >>>> +queue_cfg->cur_cb = NULL; >>>> +queue_cfg->pwr_mgmt_state = PMD_MGMT_DISABLED; >>>> +port_cfg[port_id].ref_cnt--; >>>> + >>>> +if (port_cfg[port_id].ref_cnt == 0) { >>>> +rte_free(port_cfg[port_id].queue_cfg); >>> >>> It is not safe to do so, unless device is already stopped. >>> Otherwise you need some sync mechanism here (hand-made as bpf lib, or rcu online/offline, or...) >> >> Not sure what you mean. We're not freeing the callback structure, we're >> freeing the local data structure holding the per-port status. > > What is the difference? > You still trying to free memory that might be used by your DP thread > that still executes the callback. Welp, you're right :/ I'll see what i can do to fix it. -- Thanks, Anatoly