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 CB479C348 for ; Mon, 29 Jun 2015 13:08:39 +0200 (CEST) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga103.fm.intel.com with ESMTP; 29 Jun 2015 04:08:38 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.13,698,1427785200"; d="scan'208";a="736795204" Received: from irsmsx106.ger.corp.intel.com ([163.33.3.31]) by fmsmga001.fm.intel.com with ESMTP; 29 Jun 2015 04:08:38 -0700 Received: from irsmsx156.ger.corp.intel.com (10.108.20.68) by IRSMSX106.ger.corp.intel.com (163.33.3.31) with Microsoft SMTP Server (TLS) id 14.3.224.2; Mon, 29 Jun 2015 12:08:28 +0100 Received: from irsmsx105.ger.corp.intel.com ([169.254.7.245]) by IRSMSX156.ger.corp.intel.com ([169.254.3.125]) with mapi id 14.03.0224.002; Mon, 29 Jun 2015 12:08:28 +0100 From: "Ananyev, Konstantin" To: "Qiu, Michael" , "Iremonger, Bernard" , "dev@dpdk.org" Thread-Topic: [PATCH 1/2 v4] fm10k: Free queues when close port Thread-Index: AQHQr/+3HJpVQoSGjUuB0ZdZmwfWvJ3DVocA Date: Mon, 29 Jun 2015 11:08:28 +0000 Message-ID: <2601191342CEEE43887BDE71AB97725836A1F240@irsmsx105.ger.corp.intel.com> References: <1434702717-11877-1-git-send-email-michael.qiu@intel.com> <1435307390-20140-1-git-send-email-michael.qiu@intel.com> <1435307390-20140-2-git-send-email-michael.qiu@intel.com> <8CEF83825BEC744B83065625E567D7C204A422AD@IRSMSX108.ger.corp.intel.com> <533710CFB86FA344BFBF2D6802E60286046A5FD7@SHSMSX101.ccr.corp.intel.com> <8CEF83825BEC744B83065625E567D7C204A42BB8@IRSMSX108.ger.corp.intel.com> <533710CFB86FA344BFBF2D6802E60286046A6343@SHSMSX101.ccr.corp.intel.com> In-Reply-To: <533710CFB86FA344BFBF2D6802E60286046A6343@SHSMSX101.ccr.corp.intel.com> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [163.33.239.181] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "He, Shaopeng" Subject: Re: [dpdk-dev] [PATCH 1/2 v4] fm10k: Free queues when close port X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2015 11:08:40 -0000 Hi Michael, > -----Original Message----- > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Qiu, Michael > Sent: Monday, June 29, 2015 10:21 AM > To: Iremonger, Bernard; dev@dpdk.org > Cc: He, Shaopeng > Subject: Re: [dpdk-dev] [PATCH 1/2 v4] fm10k: Free queues when close port >=20 > On 6/29/2015 4:57 PM, Iremonger, Bernard wrote: > >> -----Original Message----- > >> From: Qiu, Michael > >> Sent: Monday, June 29, 2015 9:17 AM > >> To: Iremonger, Bernard; dev@dpdk.org > >> Cc: Chen, Jing D; He, Shaopeng > >> Subject: Re: [PATCH 1/2 v4] fm10k: Free queues when close port > >> > >> On 6/26/2015 7:02 PM, Iremonger, Bernard wrote: > >>>> -----Original Message----- > >>>> From: Qiu, Michael > >>>> Sent: Friday, June 26, 2015 9:30 AM > >>>> To: dev@dpdk.org > >>>> Cc: Chen, Jing D; He, Shaopeng; Iremonger, Bernard; Qiu, Michael > >>>> Subject: [PATCH 1/2 v4] fm10k: Free queues when close port > >>>> > >>>> When close a port, lots of memory should be released, such as > >>>> software rings, queues, etc. > >>>> > >>>> Signed-off-by: Michael Qiu > >>>> --- > >>> Hi Michael, > >>> > >>> There are 2 comments inline > >>> > >>>> drivers/net/fm10k/fm10k_ethdev.c | 37 > >>>> +++++++++++++++++++++++++++++++++---- > >>>> 1 file changed, 33 insertions(+), 4 deletions(-) > >>>> > >>>> diff --git a/drivers/net/fm10k/fm10k_ethdev.c > >>>> b/drivers/net/fm10k/fm10k_ethdev.c > >>>> index 406c350..eba7228 100644 > >>>> --- a/drivers/net/fm10k/fm10k_ethdev.c > >>>> +++ b/drivers/net/fm10k/fm10k_ethdev.c > >>>> @@ -65,6 +65,8 @@ static void > >>>> fm10k_MAC_filter_set(struct rte_eth_dev *dev, const u8 *mac, bool > >>>> add); static void fm10k_MACVLAN_remove_all(struct rte_eth_dev > >> *dev); > >>>> +static void fm10k_tx_queue_release(void *queue); static void > >>>> +fm10k_rx_queue_release(void *queue); > >>>> > >>>> static void > >>>> fm10k_mbx_initlock(struct fm10k_hw *hw) @@ -809,11 +811,37 @@ > >>>> fm10k_dev_stop(struct rte_eth_dev *dev) > >>>> > >>>> PMD_INIT_FUNC_TRACE(); > >>>> > >>>> - for (i =3D 0; i < dev->data->nb_tx_queues; i++) > >>>> - fm10k_dev_tx_queue_stop(dev, i); > >>>> + if (dev->data->tx_queues) > >>>> + for (i =3D 0; i < dev->data->nb_tx_queues; i++) > >>>> + fm10k_dev_tx_queue_stop(dev, i); > >>>> > >>>> - for (i =3D 0; i < dev->data->nb_rx_queues; i++) > >>>> - fm10k_dev_rx_queue_stop(dev, i); > >>>> + if (dev->data->rx_queues) > >>>> + for (i =3D 0; i < dev->data->nb_rx_queues; i++) > >>>> + fm10k_dev_rx_queue_stop(dev, i); > >>>> +} > >>>> + > >>>> +static void > >>>> +fm10k_dev_queue_release(struct rte_eth_dev *dev) { > >>>> + int i; > >>>> + > >>>> + PMD_INIT_FUNC_TRACE(); > >>>> + > >>>> + if (dev->data->tx_queues) { > >>>> + for (i =3D 0; i < dev->data->nb_tx_queues; i++) > >>>> + fm10k_tx_queue_release(dev->data- > >>>>> tx_queues[i]); > >>>> + rte_free(dev->data->tx_queues); > >>>> + dev->data->tx_queues =3D NULL; > >>> The memory for dev->data->tx_queues is not allocated in the fm10k > >>> PMD, so it should probably not be released here. > >>> I have submitted a patch today for rte_eth_dev.c to do this. > >>> /dev/patchwork/patch/5829/ > >>> > >>>> + dev->data->nb_tx_queues =3D 0; > >>>> + } > >>>> + > >>>> + if (dev->data->rx_queues) { > >>>> + for (i =3D 0; i < dev->data->nb_rx_queues; i++) > >>>> + fm10k_rx_queue_release(dev->data- > >>>>> rx_queues[i]); > >>>> + rte_free(dev->data->rx_queues); > >>>> + dev->data->rx_queues =3D NULL; > >>> The memory for dev->data->rx_queues is not allocated in the fm10k > >>> PMD, so it should probably not be released here. > >>> I have submitted a patch today for rte_eth_dev.c to do this. > >>> /dev/patchwork/patch/5829/ > >> Is it a good idea? What about to close the port for twice at a time? > >> I think it is better to do it in rte_eth_dev_close(), I will give the = comments to > >> you. > >> > >> Thanks, > >> Michael > > Hi Michael, > > Could you take a look at the comments on http://dpdk.org/dev/patchwork/= patch/5829/ >=20 > Hi, Bernard >=20 > I have give comments on it. >=20 > > The consensus is that memory should be freed in the component that allo= cated it. > > In my pmd hotplug patches I have used a flag to ensure that dev_close i= s not called twice. > > In the e1000 patch I have added a stopped flag to struct e1000_adapter. > > http://dpdk.org/dev/patchwork/patch/5655/ >=20 >=20 >=20 > I reviewed your patch about ixgbe and fvl before. But forget e1000. >=20 > In my logic, when dev->data->rx_queues is NULL, that means this device > has been closed before. What else, we even do not care about whether it > has been closed or not, when close() function be called, all memory > should be freed if exist am I right? >=20 > So, check dev->data->rx_queues whether it is NULL will be recommend in > close function, only this could avoid unsafe situations for pointer. It seems you are mixing 2 things there: Contents of dev->data->rx_queues[] is mamanged by each PMD, and yes should= be alloced and freed by each PMD. dev->data->rx_queues[] itself is allocated/reallocated and should be freed = by rte_ethdev layer. PMD, in theory, simly doesn't know how it was allocated. Konstantin >=20 > Thanks, > Michael > > Regards, > > > > Bernard. > > > > > > > > > >