From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id ACABAA0C46; Fri, 17 Sep 2021 14:51:01 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 32A9E406B4; Fri, 17 Sep 2021 14:51:01 +0200 (CEST) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) by mails.dpdk.org (Postfix) with ESMTP id D299F40689 for ; Fri, 17 Sep 2021 14:50:59 +0200 (CEST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id 26F073200905; Fri, 17 Sep 2021 08:50:58 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Fri, 17 Sep 2021 08:50:58 -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= OMfJP5oOaa0/w9rQf/IYBXLvn4LvyTkq6lsnqabMuLg=; b=LEHuCgDi5AZRWk0+ x4l33XPNu3GwLOBKoFAd3oQorHyhd4OiA6HQCOLGOaAVz8f7J8hj5nzqeU6u9VRa gMUxUSrH5qcoFoBGraP/rhI54MPdQnVjwQ+lCYoVsBb5C3Da/Wg0UB+wvA/Zw/UG wKtZLHbVxa1ef7jakyrFSgNnBa0pZm013nI7WVv6FlPfRhtsAo7/mIGLn8bF82qa nO0i3oXPswQk7S8/UmSHyCr9HeiurQ/yPiap7d4Kafhu1sK/WE77LyjTMBy3OU/l +qEYHZqUCpfCARN21b2CGAtzj6P+P4CGfjPvDOmfGrYa0XopUzff5bzejRFbgTsB xB8Zvg== 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=OMfJP5oOaa0/w9rQf/IYBXLvn4LvyTkq6lsnqabMu Lg=; b=BpaX0MREZ/+0Muqt5y45+XOLOWFlXNviK3+58AXTTHjkWITxK6ik/ho01 +u90wVliSoWxJqDFRkDMSrcGzVFFGpIWXg52zVmdXD0lXSAuGRbPFm0mM2a8Kx67 rGCPjDyHxpPKItxpiBd8xWFSpIVhkeWzJ6zwqOmwbohcYr7dcb9OixEPlPOxL9JI o0ynLkeptPrkjTIjqLr362B/VS3q0Z/nmGJ7h/+sWTGNGvMgck4iWDZ8lVnMKi2o DD5WH0swOPUlH5l5b9cYEJYcOMZDj9joV3CksdXQHwob/VQjYQIlmK9pstOA1KL1 jTukekUp03wMUVbV33P3aVlgxeshw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrudehiedghedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtqhertddttdejnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepkeethedtieevhfeigeejleegudefjeehkeekteeuveeiuedvveeu tdejveehveetnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 17 Sep 2021 08:50:56 -0400 (EDT) From: Thomas Monjalon To: Huisong Li Cc: dev@dpdk.org, ferruh.yigit@intel.com, david.marchand@redhat.com Date: Fri, 17 Sep 2021 14:50:53 +0200 Message-ID: <2969231.2FXvsJDIr2@thomas> In-Reply-To: <6982a0aa-c8b2-8e7d-78f4-1780f2b16b9f@huawei.com> References: <20210907034108.58763-1-lihuisong@huawei.com> <1958752.TgfWGWJkml@thomas> <6982a0aa-c8b2-8e7d-78f4-1780f2b16b9f@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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 17/09/2021 04:13, Huisong Li: > =E5=9C=A8 2021/9/16 18:36, Thomas Monjalon =E5=86=99=E9=81=93: > > 16/09/2021 10:01, Huisong Li: > >> =E5=9C=A8 2021/9/8 15:20, Thomas Monjalon =E5=86=99=E9=81=93: > >>> 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 a= nd close > >>>>>> 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 = freed. > >>>> 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. > >> I know what you mean. Currently, there are two ways to close PMD device > >> (rte_eth_dev_close() and rte_dev_remove()). > >> > >> For rte_dev_remove(), eth device can be closed and rte_pci_device also > >> can be freed, so it can make app not care about that. > >> > >> But dev_close() is only used to close eth device, and nothing about > >> rte_pci_device is involved in the framework layer > >> > >> call stack of dev_close(). The rte_pci_device is allocated and > >> initialized when the rte_pci_bus scans "/sys/bus/pci/devices" director= y. > >> > >> Generally, the PMD of eth devices operates on the basis of eth devices, > >> and rarely on rte_pci_device. > >=20 > > No. The PMD is doing the relation between the PCI device and the ethdev= port. >=20 > It seems that the ethdev layer can create eth devices based on=20 > rte_pci_device, but does not release rte_pci_device. No, the ethdev layer does not manage any bus. Only the PMD does that. > >> And the rte_pci_device corresponding to the eth devices managed and > >> processed by rte_pci_bus. > >> > >> So, PMD is closed only based on the port ID of the eth device, whilch > >> only shuts down eth devices, not frees rte_pci_device > >> and remove it from rte_pci_bus. > > Not really. > I do not see any PMD driver releasing rte_pci_device in dev_close(). Maybe not but we should. > > If there is no port using the PCI device, it should be released. >=20 > Yes. > > > >>>> As far as I know, most apps or examples in the DPDK project have only > >>>> 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 non= e of > >>>> the apps seem to do this. > >>> That's because from the app point of view, only ports should be manag= ed. > >>> The hardware device is managed by the PMD. > >>> Only drivers (PMDs) have to do the relation between class ports > >>> and hardware devices. > >>=20 > >> Yes. But the current app only closes the port to disable the PMD, and > >> the rte_pci_device cannot be freed. > >=20 > > Why not? >=20 > Because most apps in DPDK call dev_close() to close the eth device=20 > corresponding to a port. You don't say why the underlying PCI device could not be freed. > >> Because rte_pci_device cannot be released in dev_close() of PMD, and is > >> managed by framework layer. > >=20 > > No > > > >> Btw. Excluding rte_dev_probe() and rte_dev_remove(), it seems that the > >> DPDK framework only automatically > >> scans PCI devices, but does not automatically release PCI devices when > >> the process exits. > >=20 > > Indeed, because such freeing is the responsibility of the PMD. >=20 > Do you mean to free rte_pci_device in the dev_close() API? I mean free the PCI device in the PMD implementation of dev_close. > 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. > Would it be more appropriate to do this in rte_eal_cleanup() if it=20 > 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.