From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124])
	by inbox.dpdk.org (Postfix) with ESMTP id 8EE7FA0C56;
	Wed,  8 Sep 2021 09:20:37 +0200 (CEST)
Received: from [217.70.189.124] (localhost [127.0.0.1])
	by mails.dpdk.org (Postfix) with ESMTP id 2EED24003E;
	Wed,  8 Sep 2021 09:20:37 +0200 (CEST)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com
 [66.111.4.28]) by mails.dpdk.org (Postfix) with ESMTP id 7B3A74003C
 for <dev@dpdk.org>; Wed,  8 Sep 2021 09:20:35 +0200 (CEST)
Received: from compute6.internal (compute6.nyi.internal [10.202.2.46])
 by mailout.nyi.internal (Postfix) with ESMTP id E50375C0174;
 Wed,  8 Sep 2021 03:20:34 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162])
 by compute6.internal (MEProxy); Wed, 08 Sep 2021 03:20:34 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h=
 from:to:cc:subject:date:message-id:in-reply-to:references
 :mime-version:content-transfer-encoding:content-type; s=fm2; bh=
 4u5JrHgFYTPoigQTEYi4eRchEbs7Mv79UCl/FrnLm9U=; b=l5XwrKPXeOhiKXO8
 8crxB1KoLm3qqtFI+Y1gyjQUCsxKXTThKBcYdDIk6xQydmsrI3IoEiIVvAaVKLNn
 FxhzEJYAILHOt1KkWdoj4JvS0ifw07yzJ/IRkKSQl585u7xJstOrpzyyBFHB6oNV
 IgBCsZcFUVDP9LaXCArMTDJrLeyaOmR6Rel4nMqLKsaaZdN4firfZBbtg39KIli7
 dQEG8FnW0a2/c8ZPzVW0B0VmlAqZKVccy3zv/YdXieTHlpTHr7/POAv9YHcYg09C
 sHhlulqck2mbrWPILnnGvAaQCcuITY0uXjrNBPe7hUH/Dkk0eaaPskF5v6aKAqdM
 NgiL7w==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
 messagingengine.com; h=cc:content-transfer-encoding:content-type
 :date:from:in-reply-to:message-id:mime-version:references
 :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender
 :x-sasl-enc; s=fm3; bh=4u5JrHgFYTPoigQTEYi4eRchEbs7Mv79UCl/FrnLm
 9U=; b=t6bCNWCzRGvwQqcAYE4AXPCUALH5VTn6VliNDVzs0w0C0gdqnDBeDOzYF
 m4aD/E0FfgzbCnSh9egggprVQkbHfAybIOfamH3zDNjiVR1qWOSTbmTKxVrPw1gW
 hG6kcOel6FfOer18aRmzCUyoYaPa7wdZ9sJhy9D4EXEC6hMZSYLYSIDiNcCy6v0I
 BlPBlq3icjCt7KmjN4LqXyVhzLsZmPj7JqRK3W5sDAUMa5hiDLiIcjVLwgKFN8SZ
 rx0kbzC2GcOWJKohzl4UWNza3IQHhXsenCSh8d6esd2PgoPlp9v27h5vaWN9KSU1
 rO/Y7LSsMBQC9RxIPbVuRaAg+spBQ==
X-ME-Sender: <xms:QmQ4YTe5Mu5rJ905YglPpbyOMfNYgmNeqBrlQzVJQwPjzyJKH391Zg>
 <xme:QmQ4YZNiqrYntjuGqwGdFUfie0i625RkQDqiw77rbDkxcFU17fDdVl33ojEpWIUDO
 gCnXjbGmY_OJ9d6gg>
X-ME-Received: <xmr:QmQ4YchiACxOGxOtMoga8e7dINcmtFBSEOYp2odQ_0e0EbVOEuKu1-P4ihprLxMXMdcigOBlGSURz1OOqDn0MfafcQ>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrudefiedgudduhecutefuodetggdotefrod
 ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh
 necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd
 enucfjughrpefhvffufffkjghfggfgtgesthhqredttddtjeenucfhrhhomhepvfhhohhm
 rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc
 ggtffrrghtthgvrhhnpeekteehtdeivefhieegjeelgedufeejheekkeetueevieeuvdev
 uedtjeevheevteenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh
 hrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght
X-ME-Proxy: <xmx:QmQ4YU8rLdp6dVNQgDeERVGVjbQ36HNh5RCdujqM5TGRePSncZDD-Q>
 <xmx:QmQ4YfsuPCUsu9fiq5nJ198a905DTbpDKjlsJQ1SEC3f2AkIEW3yGQ>
 <xmx:QmQ4YTEfIGcNCORacD7Ks9ItvT2noW6F4d2mcDZP35ayF0m47uVmzA>
 <xmx:QmQ4YY4AAposZRm-4jfLpQnnGYGB_Xabhrq3D31UV1Bcbqs4-4EvjA>
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed,
 8 Sep 2021 03:20:33 -0400 (EDT)
From: Thomas Monjalon <thomas@monjalon.net>
To: Huisong Li <lihuisong@huawei.com>
Cc: dev@dpdk.org, ferruh.yigit@intel.com, david.marchand@redhat.com
Date: Wed, 08 Sep 2021 09:20:31 +0200
Message-ID: <4929922.EBv6eS3NRu@thomas>
In-Reply-To: <76ee3238-5d1f-70c5-3ec1-92662dea2185@huawei.com>
References: <20210907034108.58763-1-lihuisong@huawei.com>
 <2757246.qzpMWD9H8a@thomas> <76ee3238-5d1f-70c5-3ec1-92662dea2185@huawei.com>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [dpdk-dev] [RFC V1] examples/l3fwd-power: fix memory leak for
 rte_pci_device
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

08/09/2021 04:01, Huisong Li:
> =E5=9C=A8 2021/9/7 16:53, Thomas Monjalon =E5=86=99=E9=81=93:
> > 07/09/2021 05:41, Huisong Li:
> >> Calling rte_eth_dev_close() will release resources of eth device and c=
lose
> >> it. But rte_pci_device struct isn't released when app exit, which will=
 lead
> >> to memory leak.
> > That's a PMD issue.
> > When the last port of a PCI device is closed, the device should be free=
d.
>=20
> Why is this a PMD problem? I don't understand.

In the PMD close function, freeing of PCI device must be managed,
so the app doesn't have to bother.

> As far as I know, most apps or examples in the DPDK project have only=20
> one port for a pci device.

The number of ports per PCI device is driver-specific.

> When the port is closed, the rte_pci_device should be freed. But none of=
=20
> the apps seem to do this.

That's because from the app point of view, only ports should be managed.
The hardware device is managed by the PMD.
Only drivers (PMDs) have to do the relation between class ports
and hardware devices.

> >> +		/* Retrieve device address in eth device before closing it. */
> >> +		eth_dev =3D &rte_eth_devices[portid];
> > You should not access this array, considered internal.
>=20
> We have to save the address of rte_device to free rte_pci_device before=20
> closing eth device.
>=20
> Because the the device address in rte_eth_dev struct will be set to a=20
> NULL after closing eth device.
>=20
> It's also handled in OVS in this way.

No you don't have to call rte_dev_remove at all from an app.

> >> +		rte_dev =3D eth_dev->device;
> >>   		rte_eth_dev_close(portid);
> >> +		ret =3D rte_dev_remove(rte_dev);