Thread (17 messages) 17 messages, 2 authors, 2021-10-08

Re: [dpdk-dev] [RFC V1] examples/l3fwd-power: fix memory leak for rte_pci_device

From: Huisong Li <lihuisong@huawei.com>
Date: 2021-09-30 06:28:45

Hi. Thomas

I've summed up our previous discussion.

Can you look at the final proposal again?

Do you think we should deal with the problem better?


在 2021/9/27 9:44, Huisong Li 写道:
在 2021/9/27 3:16, Thomas Monjalon 写道:
quoted
26/09/2021 14:20, Huisong Li:
quoted
在 2021/9/18 16:46, Thomas Monjalon 写道:
quoted
18/09/2021 05:24, Huisong Li:
quoted
在 2021/9/17 20:50, Thomas Monjalon 写道:
quoted
17/09/2021 04:13, Huisong Li:
quoted
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.
quoted
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.
quoted
quoted
quoted
quoted
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?
1. This RFC patch intended to free rte_pci_device in DPDK app by calling

rte_dev_remove() after calling dev_close().

2. For the above-mentioned usage in OVS-DPDK, please see function

netdev_dpdk_destruct() in lib/netdev-dpdk.c.

3. Later, you suggest that the release of rte_pci_device should be done

in the dev_close() API, not in the rte_eal_init() which is not real-time.

To sum up, the above proposal comes out.
quoted
It may deserve a separate mail thread.


.
.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help