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 7DC3EA0C47; Tue, 12 Oct 2021 17:33:57 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 42AC041149; Tue, 12 Oct 2021 17:33:57 +0200 (CEST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by mails.dpdk.org (Postfix) with ESMTP id 7600B4113A for ; Tue, 12 Oct 2021 17:33:56 +0200 (CEST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 259005C01A8; Tue, 12 Oct 2021 11:33:56 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Tue, 12 Oct 2021 11:33:56 -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= ofxXshTZGfRoswp5gR9py5KfFgpk8robTj+15M0jhDY=; b=fuSgXNG2ibvPLffo sO7/8n4ltR4X0jLTmPmhbbBrNi25mufsWPEdXApCNxin7ddbtak9FN8ql4nxrHec 5qV+sFXIDMeMweXVaAgFdOw+fJmKHOVZBQfxU9ttShodMbVnPjJkU3u55Esmumcm eGocNXllKWqGJnHieWiDBv3IQ4i7TgYM/NJcKmQjmXCDX7ic5j8+7RL6HVJsUKK1 xLHXpcGGVGudmn+4oPDFMyVOMS9gZG6t+TXZb3U2/jiRF1p5VEDKqzrVjNB1pmH4 qVLsuW0PYzrwv1ag7/MqgTaIvgCn00Y6PDEdpCUj979nqbx2cQ5D57y5meu4rx+o MksJ2Q== 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=fm1; bh=ofxXshTZGfRoswp5gR9py5KfFgpk8robTj+15M0jh DY=; b=OKnTbVKZHyfP3HWXDVFwW0iJTFRQf2L0bTlyW9F+/O/Csnb332kfRJU0o RLfj52gHtq0FoGRAn7krijihogMUcSk4esb2X4L6nd7w67ukbR4TawcKirs7wnmX jgWMX455eEm8JJPcRuSumZ9eny6w5pJ+AeJZXc9ziXjZnxGUc8Aewgyymvp1kYid rQyJv+TV1hquMzmjJw1ejfDLfuygnUxJ6NC4x/7XM0HjPgTbnuvLc8mIoqyTzcqu 6sGS7vlAZrmZrx04HiJy+sUIEKJkMpdydv5X3ctAIiSTvOTiHV8HW6PzPDvZTC9h WOxl6080cnxWBOQqjxunISy8Lgeeg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrvddtkedgkeejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepudeggfdvfeduffdtfeeglefghfeukefgfffhueejtdetuedtjeeu ieeivdffgeehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 12 Oct 2021 11:33:53 -0400 (EDT) From: Thomas Monjalon To: Huisong Li Cc: dev@dpdk.org, ferruh.yigit@intel.com, aman.deep.singh@intel.com, andrew.rybchenko@oktetlabs.ru, anatoly.burakov@intel.com Date: Tue, 12 Oct 2021 17:33:51 +0200 Message-ID: <2527815.Doo92MvZa3@thomas> In-Reply-To: <20211012113934.23611-1-lihuisong@huawei.com> References: <1627908397-51565-1-git-send-email-lihuisong@huawei.com> <20211012113934.23611-1-lihuisong@huawei.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH V2] ethdev: fix eth device released repeatedly 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" 12/10/2021 13:39, Huisong Li: > The rte_eth_dev_pci_generic_remove() will be called to detach an Ethernet > device when App calls rte_dev_remove() to detach a pci device. In addition, > the rte_eth_dev_close() can also detach an Ethernet device. > In secondary process, if App first calls rte_eth_dev_close() and then calls > rte_dev_remove(), because rte_eth_dev_close() doesn't clear "eth_dev->data" It would be clearer if you start this sentence with: "In secondary process, rte_eth_dev_close() doesn't clear eth_dev->data." Then you can explain that if calling rte_dev_remove() after rte_eth_dev_close(), etc... > , the address of the released Ethernet device can still be found by device > name. As a result, the Ethernet device will be released repeatedly in this > case. The state of the Ethernet device is equal to RTE_ETH_DEV_UNUSED after > calling rte_eth_dev_close(). Use this state to avoid this problem. > > Signed-off-by: Huisong Li > --- > + /* > + * In secondary process, if applications first call rte_eth_dev_close() > + * and then call this interface, because rte_eth_dev_close() doesn't > + * clear eth_dev->data, the address of the released Ethernet device can > + * still be found by device name. As a result, the Ethernet device will > + * be released repeatedly in this case. > + * The state of the Ethernet device is equal to RTE_ETH_DEV_UNUSED after > + * calling rte_eth_dev_close(). Use this state to avoid this problem. This is a comment for the commit log. Inside the code, we should be more to the point. I suggest this comment: /* A released port can be found by its name in shared memory. */ > + */ > + if (rte_eal_process_type() != RTE_PROC_PRIMARY && Better to directly compare with RTE_PROC_SECONDARY > + eth_dev->state == RTE_ETH_DEV_UNUSED) { > + RTE_ETHDEV_LOG(INFO, "The ethdev port has been released."); Not sure we need any log here. > + return 0; > + }