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 3D5D4A0C4D; Fri, 13 Aug 2021 08:13:17 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id AF11740DF4; Fri, 13 Aug 2021 08:13:16 +0200 (CEST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by mails.dpdk.org (Postfix) with ESMTP id B41B040151 for ; Fri, 13 Aug 2021 08:13:14 +0200 (CEST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 6028B5C00B1; Fri, 13 Aug 2021 02:13:14 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Fri, 13 Aug 2021 02:13:14 -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=fm1; bh= TnYZci2ctee5E1be+rn/kOXQ1VSkevz1TPj/u4Qwq/Q=; b=QBTzFtAkClIYgxuJ 1Y862XgyKrRSaj3G+P3adDsdwSnSVa5DTcKvZcyM0P24xE2gfRLKv6kLhWEoq8E2 +gEUWDM4jq4P9lF8AW2JIe4vbA+uIQXBIiY/cxz4gkBmzK168uRRP9vb8fKT2NDt vYat7b2VImQSy0yUEvQ+LWD92ryfCCkZ+hRu5b7KBMoNfSN/NcvgJvO4/JU2kBpE 6ACxVzEqwZouNMVixEKku2ySZ5Dx7tMrf2ZY8Fw92E4DaH7fxAWo5Ww9Zm32Kzb9 RTHMb7IpnLSDkRU5NObfe5xZovs4zFGQN/6vcTpPVAVZOEKucTtJ8ubLPTYUhMl6 AVoiXA== 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=TnYZci2ctee5E1be+rn/kOXQ1VSkevz1TPj/u4Qwq /Q=; b=TiHeeV9UT9MQIrtJnqaa4Wmq/C4VrJno3qA025OCCN3tNWTliDvalnp49 J08YjPzbce40SGoUZxURrhZm30seHTR3S4ijkfSvuYUN3iOI3Xk7J39lWSe2RhYx cpX6c3pJemHor+mtreIp82RXIwZVsF2b/p9oQRwUmO+K8aYXK7PYVpbK4ZuoNKT2 lku2m9QLEYY928ZMhL8Wcko8Cb3efZb03B/tROQqPASezZtTY2J9k7cthz4p+add jpm8Y1wOG7xMOJwKe5ZxSSfR6t5vihQq+9Etedq2K0uktNdvSDrq2UhfbWKFWwJk hOyIamSUgNmYWcOG0R4v/WRGt3Kcw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrkeeggddutdegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtqhertddttdejnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepkeethedtieevhfeigeejleegudefjeehkeekteeuveeiuedvveeu tdejveehveetnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 13 Aug 2021 02:13:10 -0400 (EDT) From: Thomas Monjalon To: Huisong Li Cc: "Yigit, Ferruh" , Andrew Rybchenko , "dev@dpdk.org" Date: Fri, 13 Aug 2021 08:12:59 +0200 Message-ID: <21383486.34YfpWhNxb@thomas> In-Reply-To: <9670389d-ebbc-9d9c-0cac-c7e8826ecb6f@huawei.com> References: <1627908397-51565-1-git-send-email-lihuisong@huawei.com> <1627957839-38279-1-git-send-email-lihuisong@huawei.com> <9670389d-ebbc-9d9c-0cac-c7e8826ecb6f@huawei.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [RFC V2] ethdev: fix issue that dev close in PMD calls twice 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" 13/08/2021 04:11, Huisong Li: > Hi, all >=20 > This patch can enhance the security of device uninstallation to=20 > eliminate dependency on user usage methods. >=20 > Can you check this patch? >=20 >=20 > =E5=9C=A8 2021/8/3 10:30, Huisong Li =E5=86=99=E9=81=93: > > Ethernet devices in DPDK can be released by rte_eth_dev_close() and > > rte_dev_remove(). These APIs both call xxx_dev_close() in PMD layer > > to uninstall hardware. However, the two APIs do not have explicit > > invocation restrictions. In other words, at the ethdev layer, it is > > possible to call rte_eth_dev_close() before calling rte_dev_remove() > > or rte_eal_hotplug_remove(). In such a bad scenario, It is not a bad scenario. If there is no more port for the device after calling close, the device should be removed automatically. Keep in mind "close" is for one port, "remove" is for the entire device which can have more than one port. > > the primary > > process may be fine, but it may cause that xxx_dev_close() in the PMD > > layer will be called twice in the secondary process. So this patch > > fixes it. If a port is closed in primary, it should be the same in secondary. > > + /* > > + * The eth_dev->data->name doesn't be cleared by the secondary proces= s, > > + * so above "eth_dev" isn't NULL after rte_eth_dev_close() called. This assumption is not clear. All should be closed together. > > + * Namely, whether "eth_dev" is NULL cannot be used to determine whet= her > > + * an ethdev port has been released. > > + * For both primary process and secondary process, eth_dev->state is > > + * RTE_ETH_DEV_UNUSED, which means the ethdev port has been released. > > + */ > > + if (eth_dev->state =3D=3D RTE_ETH_DEV_UNUSED) { > > + RTE_ETHDEV_LOG(INFO, "The ethdev port has been released."); > > + return 0; > > + }