> -----Original Message----- > From: Thomas Monjalon <tho...@monjalon.net> > Sent: Tuesday, September 29, 2020 07:14 > To: dev@dpdk.org > Cc: Yigit, Ferruh <ferruh.yi...@intel.com>; arybche...@solarflare.com; > Shijith Thotton > <sthot...@marvell.com>; Srisivasubramanian Srinivasan > <sriniva...@marvell.com>; Heinrich Kuhn > <heinrich.k...@netronome.com>; Alfredo Cardigliano <cardigli...@ntop.org>; > Liron Himi > <lir...@marvell.com>; Ray Kinsella <m...@ashroe.eu>; Neil Horman > <nhor...@tuxdriver.com>; John W. > Linville <linvi...@tuxdriver.com>; Loftus, Ciara <ciara.lof...@intel.com>; > Zhang, Qi Z > <qi.z.zh...@intel.com>; Shepard Siegel <shepard.sie...@atomicrules.com>; Ed > Czeck > <ed.cz...@atomicrules.com>; John Miller <john.mil...@atomicrules.com>; Igor > Russkikh > <igor.russk...@aquantia.com>; Pavel Belous <pavel.bel...@aquantia.com>; > Steven Webster > <steven.webs...@windriver.com>; Matt Peters <matt.pet...@windriver.com>; > Somalapuram Amaranath > <asoma...@amd.com>; Rasesh Mody <rm...@marvell.com>; Shahed Shaikh > <shsha...@marvell.com>; Ajit > Khaparde <ajit.khapa...@broadcom.com>; Somnath Kotur > <somnath.ko...@broadcom.com>; Chas Williams > <ch...@att.com>; Wei Hu (Xavier) <xavier.hu...@huawei.com>; Rahul Lakkireddy > <rahul.lakkire...@chelsio.com>; Hemant Agrawal <hemant.agra...@nxp.com>; > Sachin Saxena > <sachin.sax...@oss.nxp.com>; Guo, Jia <jia....@intel.com>; Wang, Haiyue > <haiyue.w...@intel.com>; > Marcin Wojtas <m...@semihalf.com>; Michal Krawczyk <m...@semihalf.com>; Guy > Tzalik <gtza...@amazon.com>; > Evgeny Schemeilin <evge...@amazon.com>; Igor Chauskin <igo...@amazon.com>; > Gagandeep Singh > <g.si...@nxp.com>; John Daley <johnd...@cisco.com>; Hyong Youb Kim > <hyon...@cisco.com>; Gaetan Rivet > <gr...@u256.net>; Wang, Xiao W <xiao.w.w...@intel.com>; Ziyang Xuan > <xuanziya...@huawei.com>; Xiaoyun > Wang <cloud.wangxiao...@huawei.com>; Guoyang Zhou <zhouguoy...@huawei.com>; > Min Hu (Connor) > <humi...@huawei.com>; Yisen Zhuang <yisen.zhu...@huawei.com>; Xing, Beilei > <beilei.x...@intel.com>; Wu, > Jingjing <jingjing...@intel.com>; Yang, Qiming <qiming.y...@intel.com>; Jakub > Grajciar > <jgraj...@cisco.com>; Matan Azrad <ma...@nvidia.com>; Shahaf Shuler > <shah...@nvidia.com>; Viacheslav > Ovsiienko <viachesl...@nvidia.com>; Zyta Szpak <z...@semihalf.com>; Stephen > Hemminger > <sthem...@microsoft.com>; K. Y. Srinivasan <k...@microsoft.com>; Haiyang > Zhang <haiya...@microsoft.com>; > Long Li <lon...@microsoft.com>; Martin Spinler <spin...@cesnet.cz>; Tetsuya > Mukawa > <mtetsu...@gmail.com>; Harman Kalra <hka...@marvell.com>; Jerin Jacob > <jer...@marvell.com>; Nithin > Dabilpuram <ndabilpu...@marvell.com>; Kiran Kumar K > <kirankum...@marvell.com>; Akhil Goyal > <akhil.go...@nxp.com>; Richardson, Bruce <bruce.richard...@intel.com>; Singh, > Jasvinder > <jasvinder.si...@intel.com>; Dumitrescu, Cristian > <cristian.dumitre...@intel.com>; Wiles, Keith > <keith.wi...@intel.com>; Maxime Coquelin <maxime.coque...@redhat.com>; Xia, > Chenbo > <chenbo....@intel.com>; Wang, Zhihong <zhihong.w...@intel.com>; Yong Wang > <yongw...@vmware.com> > Subject: [PATCH v3 21/29] ethdev: remove old close behaviour > > The temporary flag RTE_ETH_DEV_CLOSE_REMOVE is removed. > It was introduced in DPDK 18.11 in order to give time for PMDs to migrate. > > The old behaviour was to free only queues when closing a port. > The new behaviour is calling rte_eth_dev_release_port() which does > three more tasks: > - trigger event callback > - reset state and few pointers > - free all generic port resources > > The private port resources must be released in the .dev_close callback. > > The .remove callback should: > - call .dev_close callback > - call rte_eth_dev_release_port() > - free multi-port device shared resources > > Despite waiting two years, some drivers have not migrated, > so they may hit issues with the incompatible new behaviour. > After sending emails, adding logs, and announcing the deprecation, > the only last solution is to declare these drivers as unmaintained: > ionic, liquidio, nfp > Below is a summary of what to implement in those drivers. > > * The freeing of private port resources must be moved > 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" 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. > > Cc: Shijith Thotton <sthot...@marvell.com> > Cc: Srisivasubramanian Srinivasan <sriniva...@marvell.com> > Cc: Heinrich Kuhn <heinrich.k...@netronome.com> > Cc: Alfredo Cardigliano <cardigli...@ntop.org> > > Signed-off-by: Thomas Monjalon <tho...@monjalon.net> > Reviewed-by: Liron Himi <lir...@marvell.com> > ---
> drivers/net/e1000/em_ethdev.c | 5 ----- > drivers/net/e1000/igb_ethdev.c | 10 ---------- > drivers/net/igc/igc_ethdev.c | 5 ----- > drivers/net/ixgbe/ixgbe_ethdev.c | 10 ---------- For e1000/igc/ixgbe Reviewed-by: Haiyue Wang <haiyue.w...@intel.com> > 2.28.0
