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 CCFC2A0C41; Thu, 16 Sep 2021 12:36:30 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 53D7C40151; Thu, 16 Sep 2021 12:36:30 +0200 (CEST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by mails.dpdk.org (Postfix) with ESMTP id 19CC24003F for ; Thu, 16 Sep 2021 12:36:29 +0200 (CEST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 98DF85C01BD; Thu, 16 Sep 2021 06:36:28 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Thu, 16 Sep 2021 06:36:28 -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= zosOIZbCUbgtueOUPh9naSSdITW/ZxY8hhf1O3dUW70=; b=qGF3f/wbFXhFtrZD 6138l19OVlPkZ71r5SXq1p+iM7e1U3zms/BwcC9g97dgqmwWKViXW53TEmFFpW3C NqBYpPQTKevOkCVhYp9m3tuyjHA/IFfWtYOvAlZpxE62/EChleQ8+9L7GMHEb9mB /7PrzTkT4bLbPc6dnyYFRXPjEGKatS44rWR2s7Xpr41RMAaHAx+ojZ6pptJ6DyaD AU9ytzCLvzkJzZ/J1wHE5hovafUPced0ZQfK8eWNNpG/xW1iE5pxzY1sztiZrJKU 1VzAXQfWFRSTSniU17blm7o9XlxyFrsP7sFPty2K/4b46UJgSi6zRYB6pQWmZERa zU3vJQ== 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=zosOIZbCUbgtueOUPh9naSSdITW/ZxY8hhf1O3dUW 70=; b=Xn3hK/q9ou/n3soE8yisv3kfYr+e59Hah6WlZWdz/WXrry3N9Pb7BuErx tdaobR6X0EYmFX1PTJUJ2QvGVbgFmeoaBTYMbCE2JqX2GWN4JlYGDcTCfGxOnnpX 44Aw6a1Jn6uyBpbnR9BxiAFkCI0PqNtj2ma89nHDNSTi7LvlRpa6qYjmgiSb97fS 4J6gMM3DEwpjsl8kgDmU0pL3Yzf+NhwDM8ujUapQlGzJeQviDOnQ00rDaHYnXNUM PYOlu11VcI4+LMBxAb+73cJ1OUlySJV3EkWRyEK8AHMXf6vlpm8bSmnoCquVKAL5 5PH4jhxsKjINpvnEVAjqfqUNpGAKA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrudehgedgvdehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtqhertddttdejnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepkeethedtieevhfeigeejleegudefjeehkeekteeuveeiuedvveeu tdejveehveetnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 16 Sep 2021 06:36:26 -0400 (EDT) From: Thomas Monjalon To: Huisong Li Cc: dev@dpdk.org, ferruh.yigit@intel.com, david.marchand@redhat.com Date: Thu, 16 Sep 2021 12:36:25 +0200 Message-ID: <1958752.TgfWGWJkml@thomas> In-Reply-To: <579c8578-01b6-3189-cc52-eec2c49a47bd@huawei.com> References: <20210907034108.58763-1-lihuisong@huawei.com> <4929922.EBv6eS3NRu@thomas> <579c8578-01b6-3189-cc52-eec2c49a47bd@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" 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 and= close > >>>> it. But rte_pci_device struct isn't released when app exit, which wi= ll lead > >>>> to memory leak. > >>> That's a PMD issue. > >>> When the last port of a PCI device is closed, the device should be fr= eed. > >> Why is this a PMD problem? I don't understand. > >=20 > > In the PMD close function, freeing of PCI device must be managed, > > so the app doesn't have to bother. >=20 > I know what you mean. Currently, there are two ways to close PMD device=20 > (rte_eth_dev_close() and rte_dev_remove()). >=20 > For rte_dev_remove(), eth device can be closed and rte_pci_device also=20 > can be freed, so it can make app not care about that. >=20 > But dev_close() is only used to close eth device, and nothing about=20 > rte_pci_device is involved in the framework layer >=20 > call stack of dev_close(). The rte_pci_device is allocated and=20 > initialized when the rte_pci_bus scans "/sys/bus/pci/devices" directory. >=20 > Generally, the PMD of eth devices operates on the basis of eth devices,=20 > and rarely on rte_pci_device. No. The PMD is doing the relation between the PCI device and the ethdev por= t. > And the rte_pci_device corresponding to the eth devices managed and=20 > processed by rte_pci_bus. >=20 > So, PMD is closed only based on the port ID of the eth device, whilch=20 > only shuts down eth devices, not frees rte_pci_device > and remove it from rte_pci_bus. Not really. If there is no port using the PCI device, it should be released. > >> 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 none = of > >> the apps seem to do this. > >=20 > > 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. >=20 > Yes. But the current app only closes the port to disable the PMD, and=20 > the rte_pci_device cannot be freed. Why not? > Because rte_pci_device cannot be released in dev_close() of PMD, and is=20 > managed by framework layer. No > Btw. Excluding rte_dev_probe() and rte_dev_remove(), it seems that the=20 > DPDK framework only automatically > scans PCI devices, but does not automatically release PCI devices when=20 > the process exits. Indeed, because such freeing is the responsibility of the PMD.