From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <dev-bounces@dpdk.org> Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 626A0A04C9; Mon, 14 Sep 2020 00:16:30 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id C247C1C07E; Mon, 14 Sep 2020 00:16:29 +0200 (CEST) Received: from new4-smtp.messagingengine.com (new4-smtp.messagingengine.com [66.111.4.230]) by dpdk.org (Postfix) with ESMTP id 758C91B3BB for <dev@dpdk.org>; Mon, 14 Sep 2020 00:16:28 +0200 (CEST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailnew.nyi.internal (Postfix) with ESMTP id 0F46458075A; Sun, 13 Sep 2020 18:16:28 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Sun, 13 Sep 2020 18:16:28 -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= N1/iGyfDHT21+auS+0ft2tTMUPh3vCo2pMAPJ64XZz0=; b=b6ouSbt6aabgrRzL upHoDUzelsWj0FLakOBWvIX8bb5khmeCLNSyPulqZ+2K8nrR12e3MRkRtGlUP4Fl TnsuqiMr3zOdle94l4BCsJiSdjkVUFh3VgtKEDSHSCZX/6bH9U2sbWB6qpqSySf5 CbAkBe5pp4xLAnw9zP0LPaR/s/E487bkTjxpWzkw56L5vyihyQx+odETSocGKse8 UlLTDTtN+YVCSGJatkvjH6qqGTvJ8WKwuFJgocr5IX7grygbG7Qs+YBS1+FZA1Mp hRYr+T/DhCBJAIdMCACr65VldhxxmQCpIctD0ltwVPE+Y7s/hfIVQ7RbOI59csUp R3iMSQ== 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=N1/iGyfDHT21+auS+0ft2tTMUPh3vCo2pMAPJ64XZ z0=; b=id6dA9BMjXKFcwityiwwpHYwmumS9WVwf0tVZebZarw2EcoeY3ZHwmVL+ n5HNVlNFCyajsT1mnnTys7ftAf/HpsfUSlHfKL/9qkvrGAzsOFWg9OdnsVSIdRd0 HBB7y2keC/LMZ27hyfhhMr3U6Q+LhPdL5pr3U6vhIOhoCGJQedFzgDudJWh4Ttgq RWhIebi6UhiB3OGZYD10GYhXDqCkAhG+Wx9Gx63gttGIRHoEyAQsqgzhwrSbBTzn tGvQ1k2KHjPr2wteRsR1T+iTgi+hybgTdb0mmF5zBelDp9c+7xHducHeADlr1m60 Xj8d+CqLZGaAehKZnOTQZe0jDpVLw== X-ME-Sender: <xms:O5peXy8MAPAeS9x2ygcpcJYeoBYyHx9YQsWYhhOtHFsfRxf-Dnr37g> <xme:O5peXyuGQYBDtR6JF38b3iLP7AqG3r_KVOtIHBvDTLAtF1rb28FcbIrgth7QeRWwc jtpyNMwzZyabQkZDw> X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrudeihedgtdejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecugg ftrfgrthhtvghrnhepffdvffejueetleefieeludduuefgteejleevfeekjeefieegheet ffdvkeefgedunecuffhomhgrihhnpeguphgukhdrohhrghenucfkphepjeejrddufeegrd dvtdefrddukeegnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhf rhhomhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth X-ME-Proxy: <xmx:O5peX4AadWsMN7RaQ8CiTVRuFAb-BeQ2kxcyry8_9Ebx2JkT9zblPA> <xmx:O5peX6e0jqmFaVqHN7yjY87RvbDxvkriguy3zbpMEIOdtbthAqoA7w> <xmx:O5peX3O5SAAJDY9T8uleXQJj5wgqsaQ0jzzWXWLmG3vnksdHbGXpPQ> <xmx:PJpeXxHAKG2tqKZjJI6Y4-Hj0u45bVcfaGTfoL4DHCQLU0IPzvQGVQ> Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 97B6A3280059; Sun, 13 Sep 2020 18:16:20 -0400 (EDT) From: Thomas Monjalon <thomas@monjalon.net> To: "John W. Linville" <linville@tuxdriver.com>, Qi Zhang <qi.z.zhang@intel.com>, Shepard Siegel <shepard.siegel@atomicrules.com>, Ed Czeck <ed.czeck@atomicrules.com>, John Miller <john.miller@atomicrules.com>, Igor Russkikh <igor.russkikh@aquantia.com>, Pavel Belous <pavel.belous@aquantia.com>, Matt Peters <matt.peters@windriver.com>, Rasesh Mody <rmody@marvell.com>, Shahed Shaikh <shshaikh@marvell.com>, Ajit Khaparde <ajit.khaparde@broadcom.com>, Somnath Kotur <somnath.kotur@broadcom.com>, Chas Williams <chas3@att.com>, Rahul Lakkireddy <rahul.lakkireddy@chelsio.com>, Hemant Agrawal <hemant.agrawal@nxp.com>, Marcin Wojtas <mw@semihalf.com>, Michal Krawczyk <mk@semihalf.com>, Guy Tzalik <gtzalik@amazon.com>, Evgeny Schemeilin <evgenys@amazon.com>, Gagandeep Singh <g.singh@nxp.com>, John Daley <johndale@cisco.com>, Hyong Youb Kim <hyonkim@cisco.com>, Gaetan Rivet <grive@u256.net>, Xiao Wang <xiao.w.wang@intel.com>, Qiming Yang <qiming.yang@intel.com>, Ferruh Yigit <ferruh.yigit@intel.com>, Shijith Thotton <sthotton@marvell.com>, Srisivasubramanian Srinivasan <srinivasan@marvell.com>, Matan Azrad <matan@mellanox.com>, Shahaf Shuler <shahafs@mellanox.com>, Zyta Szpak <zr@semihalf.com>, Liron Himi <lironh@marvell.com>, Stephen Hemminger <sthemmin@microsoft.com>, "K. Y. Srinivasan" <kys@microsoft.com>, Haiyang Zhang <haiyangz@microsoft.com>, Jerin Jacob <jerinj@marvell.com>, Bruce Richardson <bruce.richardson@intel.com>, Andrew Rybchenko <arybchenko@solarflare.com>, Jasvinder Singh <jasvinder.singh@intel.com>, Cristian Dumitrescu <cristian.dumitrescu@intel.com>, Keith Wiles <keith.wiles@intel.com>, Maciej Czekaj <mczekaj@marvell.com>, Maxime Coquelin <maxime.coquelin@redhat.com>, Zhihong Wang <zhihong.wang@intel.com>, Yong Wang <yongwang@vmware.com>, Anatoly Burakov <anatoly.burakov@intel.com>, Beilei Xing <beilei.xing@intel.com>, Jingjing Wu <jingjing.wu@intel.com>, dev@dpdk.org Cc: Rosen Xu <rosen.xu@intel.com>, dev@dpdk.org, Ciara Loftus <ciara.loftus@intel.com>, Steven Webster <steven.webster@windriver.com>, Somalapuram Amaranath <asomalap@amd.com>, xavier.huwei@huawei.com, Sachin Saxena <sachin.saxena@nxp.com>, Wei Zhao <wei.zhao1@intel.com>, Jeff Guo <jia.guo@intel.com>, Igor Chauskin <igorch@amazon.com>, Ziyang Xuan <xuanziyang2@huawei.com>, Xiaoyun Wang <cloud.wangxiaoyun@huawei.com>, Guoyang Zhou <zhouguoyang@huawei.com>, "Min Hu (Connor)" <humin29@huawei.com>, Yisen Zhuang <yisen.zhuang@huawei.com>, Alfredo Cardigliano <cardigliano@ntop.org>, Jakub Grajciar <jgrajcia@cisco.com>, Viacheslav Ovsiienko <viacheslavo@mellanox.com>, Long Li <longli@microsoft.com>, Martin Spinler <spinler@cesnet.cz>, Heinrich Kuhn <heinrich.kuhn@netronome.com>, Harman Kalra <hkalra@marvell.com>, Nithin Dabilpuram <ndabilpuram@marvell.com>, Kiran Kumar K <kirankumark@marvell.com>, Akhil Goyal <akhil.goyal@nxp.com>, ferruh.yigit@intel.com, Thomas Monjalon <thomas@monjalon.net> Date: Mon, 14 Sep 2020 00:16:17 +0200 Message-ID: <80837131.n3tlCtGQ32@thomas> In-Reply-To: <7235002.MNFtMmeBO2@thomas> References: <30528485.5cHeq7CNxZ@xps> <5248162.j6AOsuQRmx@thomas> <7235002.MNFtMmeBO2@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 <dev.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> Errors-To: dev-bounces@dpdk.org Sender: "dev" <dev-bounces@dpdk.org> The patches for removing RTE_ETH_DEV_CLOSE_REMOVE are sent: https://patches.dpdk.org/project/dpdk/list/?series=12173 11 drivers are not supporting the new behaviour correctly: bnx2x, cxgbe, dpaa, dpaa2, enetc, ionic, ipn3ke, liquidio, nfp, pfe, qede If you are the maintainer of one of these drivers, you can still consider fixing it in the next days. 12/09/2020 13:25, Thomas Monjalon: > 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.