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 64489A0C41; Thu, 30 Sep 2021 09:50:11 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id C561F410EC; Thu, 30 Sep 2021 09:50:10 +0200 (CEST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by mails.dpdk.org (Postfix) with ESMTP id E6134410EA for ; Thu, 30 Sep 2021 09:50:09 +0200 (CEST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 517A35C01B2; Thu, 30 Sep 2021 03:50:08 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Thu, 30 Sep 2021 03:50:08 -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= eD9dvuC5zBT5pL2R/QUvR13ps8/8CjFRmyLazyOtUuo=; b=KOXpuok6BLdHFS6r En1KNQku7MuWrh8+GxWZLrY4kMA1wH+gl60rG2y2ZuXE6DSVT8gpUETg5WseI35j 2BZ6JmGtbFgZa9brCkS4bfJeAhpZKIc5cbdJI8jPsYjc+YdDg8L6xZJ26UpsCfKQ w4NVokDvzft8dWqjt96UQ8MmKMPHo2lhAmQbpnzMMVexJGeAoTUCjOwcU4fg1Wnz iwXk1JEsVRpEMvfaDV7vdiaqPu9VbopKonweELPraLRhSu34kd6hn21U14y5vcZX jixEShcST+TA9yDf1fXO3FRbekeggMsyeNBbFZgiA6nwVZYdI9qgV3d4gKMtsLsb Y7dwkg== 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=eD9dvuC5zBT5pL2R/QUvR13ps8/8CjFRmyLazyOtU uo=; b=DWggW6nR7Ma8xLMBjsLnQeGxgV9Cp3wr3yusZwcF2/tlnqtZcGn9AJIZe aQSL7XS+Bvqs7E20PdLVNmI2Z0s4ETyLpT9cGVsWIPyv2GowAjuQUZf1nqmZTIib OIriBXd00v3BNF8pFzmX8lDYd+3aMMLoWURn6vf8Nd2aPfdMLV1s9ofHvy2q65Bp dIOXewamT5EO/ZJiYnzdFXqBDrqd5KU+PybLxKkBTQkkbUQsoEqo8Bqenc9AGLwi lkf+TWWis/BlchSpoyKmPoKNux/hgl4960kWw70PTRUtq9yn9df75d3BfNKseLU2 PDeBoPZYrMJctjUlICdRFqVugIJNQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrudekfedguddulecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefhvffufffkjghfggfgtgesthhqredttddtjeenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc ggtffrrghtthgvrhhnpeekteehtdeivefhieegjeelgedufeejheekkeetueevieeuvdev uedtjeevheevteenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 30 Sep 2021 03:50:07 -0400 (EDT) From: Thomas Monjalon To: Huisong Li Cc: dev@dpdk.org, ferruh.yigit@intel.com, david.marchand@redhat.com Date: Thu, 30 Sep 2021 09:50:05 +0200 Message-ID: <2162308.5El5PrcoHi@thomas> In-Reply-To: <6934941a-23e0-5466-3013-69a79c42fec0@huawei.com> References: <20210907034108.58763-1-lihuisong@huawei.com> <6934941a-23e0-5466-3013-69a79c42fec0@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" 30/09/2021 08:28, Huisong Li: > Hi. Thomas >=20 > I've summed up our previous discussion. >=20 > Can you look at the final proposal again? >=20 > Do you think we should deal with the problem better? I don't understand what is the final proposal. > =E5=9C=A8 2021/9/27 9:44, Huisong Li =E5=86=99=E9=81=93: > > > > =E5=9C=A8 2021/9/27 3:16, Thomas Monjalon =E5=86=99=E9=81=93: > >> 26/09/2021 14:20, Huisong Li: > >>> =E5=9C=A8 2021/9/18 16:46, Thomas Monjalon =E5=86=99=E9=81=93: > >>>> 18/09/2021 05:24, Huisong Li: > >>>>> =E5=9C=A8 2021/9/17 20:50, Thomas Monjalon =E5=86=99=E9=81=93: > >>>>>> 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=20 > >>>>> independent. > >>>> Yes it requires to free on both primary and secondary. > >>>> > >>>>> Is this for a scenario where there are multiple representor ports=20 > >>>>> 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=20 > >>>>>> 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 runnin= g, > >>>> we should not wait to free it. > >>> From this point of view, it seems to make sense. However,=20 > >>> 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-tim= e. > > > > To sum up, the above proposal comes out. > > > >> It may deserve a separate mail thread. > >> > >> > >> . > > . >=20