From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 0AFEBA04C8; Sat, 12 Sep 2020 13:25:56 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 0A9021C1D8; Sat, 12 Sep 2020 13:25:55 +0200 (CEST) Received: from new2-smtp.messagingengine.com (new2-smtp.messagingengine.com [66.111.4.224]) by dpdk.org (Postfix) with ESMTP id 0D8131C0CA for ; Sat, 12 Sep 2020 13:25:54 +0200 (CEST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailnew.nyi.internal (Postfix) with ESMTP id 8EA8D580186; Sat, 12 Sep 2020 07:25:50 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Sat, 12 Sep 2020 07:25:50 -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= Qu+WrZlYRNNc7t+MUJdPzobM10wi8evw1dJUwsV87JQ=; b=ikqtx6Idyl9060ZB DXUPE/SweGPghKxK0EJTRARp9hihRWB1lv03ga4x9zVNaunu4IzB4PjFYvNSz2O8 aUA1HGzSlkUJHb7/0RHgfxSdPBHjqXBgygSapfD3pE3nOYEaRnhLtHsEx8nrGifu iwT3yXyii1yLT43P4NZL+hMS8xr3uRYhaJdutTZoiojhaAKA70DQF8KfIMxZPgFB G9WF3V5LmJkroEqrQTJM+cyTTXpSEd8uTLz7prRuC9B8u7p6rAOoV1qLs+jt9BwJ eGom5oXgnM76OJyMIkIwuNPcJS+k4zMkU+XzxmmDhfwf1d6jevNB7ZX3UOuKLzvN TyHcjQ== 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=Qu+WrZlYRNNc7t+MUJdPzobM10wi8evw1dJUwsV87 JQ=; b=PgHQx+5ARq6a7pMHBnn7NNRuOPQSLYm3A2sVNbthGptum+4LU2A54kJgF dn7OkfIe1eayrHBiHbUGLKFwiJI40zKpfHfMmInHn7LvaySJA1kh3LRn8AzLmEOH f6qWwrS39DrygnyUsR8IMxnKnlN1whBS7H9tJ3CkDKBsxUGo7krKc34wnp/ur1F9 QLIQMbvGd6sWMzhtcYE1zOVYY19GG6DiRDfH2tWKqk0V4v+Q1NUwYVSjEPklzfVY w2/wsWO07cMl40//CBfqLWOE5IMSNkyAG+3ozZkA17I5iJxiawmlfnV/svK2hgVe roZdBYdsSyfh2FMH8zd4c0Oi2mqjw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrudeiuddggeduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepffdvffejueetleefieeludduuefgteejleevfeekjeefieegheet ffdvkeefgedunecuffhomhgrihhnpeguphgukhdrohhrghenucfkphepjeejrddufeegrd dvtdefrddukeegnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhf rhhomhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth 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 79A34328005D; Sat, 12 Sep 2020 07:25:40 -0400 (EDT) From: Thomas Monjalon To: "John W. Linville" , Qi Zhang , Shepard Siegel , Ed Czeck , John Miller , Igor Russkikh , Pavel Belous , Matt Peters , Rasesh Mody , Shahed Shaikh , Ajit Khaparde , Somnath Kotur , Chas Williams , Rahul Lakkireddy , Hemant Agrawal , Marcin Wojtas , Michal Krawczyk , Guy Tzalik , Evgeny Schemeilin , Gagandeep Singh , John Daley , Hyong Youb Kim , Gaetan Rivet , Xiao Wang , Qiming Yang , Ferruh Yigit , Shijith Thotton , Srisivasubramanian Srinivasan , Matan Azrad , Shahaf Shuler , Zyta Szpak , Liron Himi , Stephen Hemminger , "K. Y. Srinivasan" , Haiyang Zhang , Jerin Jacob , Bruce Richardson , Andrew Rybchenko , Jasvinder Singh , Cristian Dumitrescu , Keith Wiles , Maciej Czekaj , Maxime Coquelin , Zhihong Wang , Yong Wang , Anatoly Burakov , Beilei Xing , Jingjing Wu , dev@dpdk.org Cc: Rosen Xu , dev@dpdk.org, Ciara Loftus , Steven Webster , Somalapuram Amaranath , xavier.huwei@huawei.com, Sachin Saxena , Wei Zhao , Jeff Guo , Igor Chauskin , Ziyang Xuan , Xiaoyun Wang , Guoyang Zhou , "Min Hu (Connor)" , Yisen Zhuang , Alfredo Cardigliano , Jakub Grajciar , Viacheslav Ovsiienko , Long Li , Martin Spinler , Heinrich Kuhn , Harman Kalra , Nithin Dabilpuram , Kiran Kumar K , Akhil Goyal , ferruh.yigit@intel.com Date: Sat, 12 Sep 2020 13:25:38 +0200 Message-ID: <7235002.MNFtMmeBO2@thomas> In-Reply-To: <5248162.j6AOsuQRmx@thomas> References: <30528485.5cHeq7CNxZ@xps> <5248162.j6AOsuQRmx@thomas> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] CALL to eth PMD maintainers: complete closing of port 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" 03/08/2020 20:50, Thomas Monjalon: > 18/04/2019 12:59, Thomas Monjalon: > > Hi all, > > > > Since DPDK 18.11, the behaviour of the close operation is changed > > if RTE_ETH_DEV_CLOSE_REMOVE is enabled in the driver: > > port is released (i.e. totally freed and data erased) on close. > > This new behaviour is enabled per driver for a migration period. > > > > Looking at the code, you can see these comments: > > /* old behaviour: only free queue arrays */ > > RTE_ETHDEV_LOG(DEBUG, "Port closing is using an old behaviour.\n" > > "The driver %s should migrate to the new behaviour.\n", > > /* new behaviour: send event + reset state + free all data */ > > > > You can find an advice in the commit: > > http://git.dpdk.org/dpdk/commit/?id=23ea57a2a > > " > > When enabling RTE_ETH_DEV_CLOSE_REMOVE, > > the PMD must free all its private resources for the port, > > in its dev_close function. > > It is advised to call the dev_close function in the remove function > > in order to support removing a device without closing its ports. > > " > > > > It would be great to complete this migration for the next LTS > > version, which will be 19.11. > > For the record, it did not happen in 19.11. > > > Following drivers should be migrated: > > ( find drivers/net -mindepth 1 -maxdepth 1 -type d | cut -d/ -f3 ; git grep -l RTE_ETH_DEV_CLOSE_REMOVE drivers | cut -d/ -f3 ) | sort | uniq -u > [...] > > The progress in April 2019 was 4 of 46 (9%). > > > Please let's progress smoothly on this topic, thanks. > > More than one year later, the progress is 26 of 53 (49%). > > > The concerned maintainers (Cc) can be found with the following command: > > devtools/get-maintainer.sh $(( find drivers/net -mindepth 1 -maxdepth 1 -type d | cut -d/ -f-3 ; git grep -l RTE_ETH_DEV_CLOSE_REMOVE drivers ) | sort | uniq -u) > > We cannot wait forever. Temporary cannot be longer than 2 years. > I am going to send a deprecation notice to remove the "temporary" > flag RTE_ETH_DEV_CLOSE_REMOVE. The deprecation notice was merged in 20.08: http://mails.dpdk.org/archives/dev/2020-August/177314.html > It will break drivers which are not migrated. > It will probably help to find motivation in new priorities. > > More details on what to do can be found in this mail thread: > http://inbox.dpdk.org/dev/1748144.UFpUr2FPnr@xps/ Summary: * The freeing of private port resources must be moved in the PMD from the ".remove(device)" function to the ".dev_close(port)" function. * If a generic resource (.mac_addrs or .hash_mac_addrs) cannot be freed, it must be set to NULL in ".dev_close" PMD function to protect from subsequent rte_eth_dev_release_port() freeing. * Note 1: The generic resources are freed in rte_eth_dev_release_port(), after ".dev_close" is called in rte_eth_dev_close(), but not when calling ".dev_close" directly from the ".remove" PMD function. That's why rte_eth_dev_release_port() must still be called explicitly from ".remove(device)" after calling the ".dev_close" PMD function. * Note 2: If a device can have multiple ports, the common resources must be freed only in the ".remove(device)" function. * Note 3: The port is supposed to be in a stopped state when it is closed. If it is not the case, it is free to the PMD implementation how to react when trying to close a non-stopped port: either try to stop it automatically or just return an error.