From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id 6A32BA0679 for ; Tue, 30 Apr 2019 00:34:58 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 242BB6C9B; Tue, 30 Apr 2019 00:34:57 +0200 (CEST) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) by dpdk.org (Postfix) with ESMTP id 47DB969D4 for ; Tue, 30 Apr 2019 00:34:55 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 33E40C40; Mon, 29 Apr 2019 18:34:54 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Mon, 29 Apr 2019 18:34:54 -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=mesmtp; bh=NXLSvlaD5SAuY4u6l4H/5bV8YhsDC1Y0ddOi1JxIka4=; b=oZrlveEFEbyV cFRI4I3WvUlTLvkHROm/oR//F0ex3xiDz9z9DjxQ5ruDFOJRORh9VuD2BPsyI2sW YAvII7Xug1nhCqfVKdL4Kcc2eEhJxVpz6no4P0EcooPHyiIkfXFbTCIFmjE0yttU lkt6vc+IjsMxzcis/99LYpvE3lB9ev4= 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=fm2; bh=NXLSvlaD5SAuY4u6l4H/5bV8YhsDC1Y0ddOi1JxIk a4=; b=vM+R8JAf91QPlMB45VoPVIUFrImP8ni/NN1YEvdcYaZyX7yEbOlz5F3FI LNJVPOwVtK8qYfK3VpM1lgyB4wfcQifrdVFE6DhQE8oqG3PQQMDgAG+AYfRyQwuC MIszxWHVuDnP47nl8PDyo3RCsCu63+vM76JS5nC+3bFuxYeVf1ZahdYkJINMgtMj LHDxOA0vnPu9VlEHMh8YR4MYSMXF8VLbSWkyIg7K8n6oQ/Xe3VvWuWNLWuAfcjOM xb7rhNISZ7e8eq1HMFSWMePpKS661tHaK8hMfwad0r3ftc/7PBdnsstpV2ZKJZBO rMEH+fy7W2d8Jiw7Q0m5blCKKuo3g== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrieefgddufecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghs ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucfkph epjeejrddufeegrddvtdefrddukeegnecurfgrrhgrmhepmhgrihhlfhhrohhmpehthhho mhgrshesmhhonhhjrghlohhnrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id CA4A7E4067; Mon, 29 Apr 2019 18:34:52 -0400 (EDT) From: Thomas Monjalon To: Ferruh Yigit Cc: Xiaolong Ye , dev@dpdk.org Date: Tue, 30 Apr 2019 00:34:51 +0200 Message-ID: <8348310.0Lx1uY5diY@xps> In-Reply-To: References: <20190426050912.109813-1-xiaolong.ye@intel.com> <4288940.mimLx63fH2@xps> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="UTF-8" Subject: Re: [dpdk-dev] [PATCH v1 1/2] net/af_xdp: remove resources when port is closed X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 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" Message-ID: <20190429223451.R_5uus7Ji4QuWYFGjQJEtniMeOWQU8mDP5acHA7EsLM@z> 30/04/2019 00:28, Ferruh Yigit: > On 4/29/2019 9:14 PM, Thomas Monjalon wrote: > > 29/04/2019 19:00, Ferruh Yigit: > >> On 4/26/2019 6:09 AM, Xiaolong Ye wrote: > >>> Since 18.11, it is suggested that driver should release all its private > >>> resources at the dev_close routine. So all resources previously released > >>> in remove routine are now released at the dev_close routine, and the > >>> dev_close routine will be called in driver remove routine in order to > >>> support removing a device without closing its ports. > >>> > >>> Above behavior changes are supported by setting RTE_ETH_DEV_CLOSE_REMOVE > >>> flag during probe stage. > >>> > >>> Signed-off-by: Xiaolong Ye > >> > >> <...> > >> > >>> @@ -936,14 +940,7 @@ rte_pmd_af_xdp_remove(struct rte_vdev_device *dev) > >>> if (eth_dev == NULL) > >>> return -1; > >>> > >>> - internals = eth_dev->data->dev_private; > >>> - > >>> - rte_ring_free(internals->umem->buf_ring); > >>> - rte_memzone_free(internals->umem->mz); > >>> - rte_free(internals->umem); > >>> - > >>> - rte_eth_dev_release_port(eth_dev); > >> > >> I thinks we should keep 'rte_eth_dev_release_port()' in '.remove()' path, > >> the 'RTE_ETH_DEV_CLOSE_REMOVE' flag will take care of this in > >> 'rte_eth_dev_close()' but still needed in '.remove()' path. > > > > I don't understand your comment. > > Calling the close function looks the right thing to do in "remove". > > No concern on calling the 'close'. > My comment was to keep 'rte_eth_dev_release_port()' which this patch removes. rte_eth_dev_release_port() is called in eth_dev_close(), isn't it? > >>> - > >>> + eth_dev_close(eth_dev);