All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Monjalon <thomas@monjalon.net>
To: Huisong Li <lihuisong@huawei.com>
Cc: dev@dpdk.org, ferruh.yigit@intel.com, david.marchand@redhat.com
Subject: Re: [dpdk-dev] [RFC V1] examples/l3fwd-power: fix memory leak for rte_pci_device
Date: Sun, 26 Sep 2021 21:16:09 +0200	[thread overview]
Message-ID: <4188639.QZEZhMFxuf@thomas> (raw)
In-Reply-To: <430246ab-36ce-402f-8570-d305ada9d720@huawei.com>

26/09/2021 14:20, Huisong Li:
> 在 2021/9/18 16:46, Thomas Monjalon 写道:
> > 18/09/2021 05:24, Huisong Li:
> >> 在 2021/9/17 20:50, Thomas Monjalon 写道:
> >>> 17/09/2021 04:13, Huisong Li:
> >>>> How should PMD free it? What should we do? Any good suggestions?
> >>> Check that there is no other port sharing the same PCI device,
> >>> then call the PMD callback for rte_pci_remove_t.
> >> For primary and secondary processes, their rte_pci_device is independent.
> > Yes it requires to free on both primary and secondary.
> >
> >> Is this for a scenario where there are multiple representor ports under
> >> the same PCI address in the same processe?
> > A PCI device can have multiple physical or representor ports.
> Got it.
> >
> >>>> Would it be more appropriate to do this in rte_eal_cleanup() if it
> >>>> cann't be done in the API above?
> >>> rte_eal_cleanup is a last cleanup for what was not done earlier.
> >>> We could do that but first we should properly free devices when closed.
> >>>
> >> Totally, it is appropriate that rte_eal_cleanup is responsible for
> >> releasing devices under the pci bus.
> > Yes, but if a device is closed while the rest of the app keep running,
> > we should not wait to free it.
> 
>  From this point of view, it seems to make sense. However, according to 
> the OVS-DPDK
> 
> usage, it calls dev_close() first, and then check whether all ports 
> under the PCI address are
> 
> closed to free rte_pci_device by calling rte_dev_remove().
> 
> 
> If we do not want the user to be aware of this, and we want 
> rte_pci_device to be freed
> 
> in a timely manner. Can we add a code logic calculating the number of 
> ports under a PCI address
> 
> and calling rte_dev_remove() to rte_eth_dev_close() to free 
> rte_pci_device and delete it from rte_pci_bus?
> 
> If we do, we may need to make some extra work, otherwise some 
> applications, such as OVS-DPDK, will
> 
> fail due to a second call to rte_dev_remove().

I don't understand the proposal.
Please could explain again the code path?
It may deserve a separate mail thread.



  reply	other threads:[~2021-09-26 19:16 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-07  3:41 [dpdk-dev] [RFC V1] examples/l3fwd-power: fix memory leak for rte_pci_device Huisong Li
2021-09-07  8:53 ` Thomas Monjalon
2021-09-08  2:01   ` Huisong Li
2021-09-08  7:20     ` Thomas Monjalon
2021-09-16  8:01       ` Huisong Li
2021-09-16 10:36         ` Thomas Monjalon
2021-09-17  2:13           ` Huisong Li
2021-09-17 12:50             ` Thomas Monjalon
2021-09-18  3:24               ` Huisong Li
2021-09-18  8:46                 ` Thomas Monjalon
2021-09-26 12:20                   ` Huisong Li
2021-09-26 19:16                     ` Thomas Monjalon [this message]
2021-09-27  1:44                       ` Huisong Li
2021-09-30  6:28                         ` Huisong Li
2021-09-30  7:50                           ` Thomas Monjalon
2021-10-08  6:26                             ` lihuisong (C)
2021-10-08  6:29                               ` 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=4188639.QZEZhMFxuf@thomas \
    --to=thomas@monjalon.net \
    --cc=david.marchand@redhat.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=lihuisong@huawei.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.