DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>
To: "Qiu, Michael" <michael.qiu@intel.com>,
	"Iremonger, Bernard" <bernard.iremonger@intel.com>,
	"dev@dpdk.org" <dev@dpdk.org>
Cc: "He, Shaopeng" <shaopeng.he@intel.com>
Subject: Re: [dpdk-dev] [PATCH 1/2 v4] fm10k: Free queues when close port
Date: Mon, 29 Jun 2015 11:08:28 +0000	[thread overview]
Message-ID: <2601191342CEEE43887BDE71AB97725836A1F240@irsmsx105.ger.corp.intel.com> (raw)
In-Reply-To: <533710CFB86FA344BFBF2D6802E60286046A6343@SHSMSX101.ccr.corp.intel.com>

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
> 
> 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 <michael.qiu@intel.com>
> >>>> ---
> >>> 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 = 0; i < dev->data->nb_tx_queues; i++)
> >>>> -		fm10k_dev_tx_queue_stop(dev, i);
> >>>> +	if (dev->data->tx_queues)
> >>>> +		for (i = 0; i < dev->data->nb_tx_queues; i++)
> >>>> +			fm10k_dev_tx_queue_stop(dev, i);
> >>>>
> >>>> -	for (i = 0; i < dev->data->nb_rx_queues; i++)
> >>>> -		fm10k_dev_rx_queue_stop(dev, i);
> >>>> +	if (dev->data->rx_queues)
> >>>> +		for (i = 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 = 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 = 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 = 0;
> >>>> +	}
> >>>> +
> >>>> +	if (dev->data->rx_queues) {
> >>>> +		for (i = 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 = 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/
> 
> Hi, Bernard
> 
> I have give comments on it.
> 
> > The consensus is that memory should be freed in the component that allocated it.
> > In my pmd hotplug patches I have used a flag to ensure that dev_close is not called twice.
> > In the e1000 patch I have added a stopped flag to struct e1000_adapter.
> > http://dpdk.org/dev/patchwork/patch/5655/
> 
> 
> 
> I reviewed your patch about ixgbe and fvl before. But forget e1000.
> 
> 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?
> 
> 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


> 
> Thanks,
> Michael
> > Regards,
> >
> > Bernard.
> >
> > <snip>
> >
> >
> >

  parent reply	other threads:[~2015-06-29 11:08 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-31 14:37 [dpdk-dev] [RFC PATCH] librte_pmd_fm10k: Add hotplug support for fm10k Michael Qiu
2015-06-02  8:26 ` Iremonger, Bernard
2015-06-02  9:36   ` Qiu, Michael
2015-06-10 12:21 ` [dpdk-dev] [PATCH 0/2 v2] Enable " Michael Qiu
2015-06-10 12:21   ` [dpdk-dev] [PATCH 1/2] fm10k: Free queues when close port Michael Qiu
2015-06-12  7:27     ` Chen, Jing D
2015-06-17  7:59     ` [dpdk-dev] [PATCH 1/2 v2] " Michael Qiu
2015-06-18  7:32       ` Chen, Jing D
2015-06-18 16:29       ` Iremonger, Bernard
2015-06-19  7:36         ` Qiu, Michael
2015-06-17  8:44     ` [dpdk-dev] [PATCH 2/2 v2] fm10k: Add hotplug support for fm10k Michael Qiu
2015-06-18 16:42       ` Iremonger, Bernard
2015-06-19  7:41         ` Qiu, Michael
2015-06-10 12:21   ` [dpdk-dev] [PATCH 2/2] " Michael Qiu
2015-06-10 12:24   ` [dpdk-dev] [PATCH 0/2 v2] Enable " Qiu, Michael
2015-06-19  8:31   ` [dpdk-dev] [PATCH 0/2 v3] " Michael Qiu
2015-06-19  8:31     ` [dpdk-dev] [PATCH 1/2 v3] fm10k: Free queues when close port Michael Qiu
2015-06-19  8:31     ` [dpdk-dev] [PATCH 2/2 v2] fm10k: Add hotplug support for fm10k Michael Qiu
2015-06-19  8:36       ` Qiu, Michael
2015-06-26  8:29     ` [dpdk-dev] [PATCH 0/2 v4] Enable " Michael Qiu
2015-06-26  8:29       ` [dpdk-dev] [PATCH 1/2 v4] fm10k: Free queues when close port Michael Qiu
2015-06-26 11:02         ` Iremonger, Bernard
2015-06-29  8:17           ` Qiu, Michael
2015-06-29  8:57             ` Iremonger, Bernard
2015-06-29  9:20               ` Qiu, Michael
2015-06-29  9:53                 ` Iremonger, Bernard
2015-06-29 14:58                   ` Qiu, Michael
2015-06-29 15:15                     ` Qiu, Michael
2015-06-29 11:08                 ` Ananyev, Konstantin [this message]
2015-06-29 15:14                   ` Qiu, Michael
2015-06-26  8:29       ` [dpdk-dev] [PATCH 2/2 v4] fm10k: Add hotplug support for fm10k Michael Qiu
2015-07-14 12:45       ` [dpdk-dev] [PATCH 0/2 v5] Enable " Michael Qiu
2015-07-14 12:45         ` [dpdk-dev] [PATCH 1/2 v5] fm10k: Free queues when close port Michael Qiu
2015-07-14 12:45         ` [dpdk-dev] [PATCH 2/2 v5] fm10k: Add hotplug support for fm10k Michael Qiu
2015-07-19 20:26         ` [dpdk-dev] [PATCH 0/2 v5] Enable " Thomas Monjalon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2601191342CEEE43887BDE71AB97725836A1F240@irsmsx105.ger.corp.intel.com \
    --to=konstantin.ananyev@intel.com \
    --cc=bernard.iremonger@intel.com \
    --cc=dev@dpdk.org \
    --cc=michael.qiu@intel.com \
    --cc=shaopeng.he@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).