Hi Thomas, Ipn3ke is based on ifpga_bus, and all ethdevs created from ipn3ke are representors. So it's no need to add RTE_ETH_DEV_CLOSE_REMOVE flags into ipn3ke driver.
Thanks, Rosen > -----Original Message----- > From: Thomas Monjalon <[email protected]> > Sent: Monday, September 14, 2020 6:16 > To: John W. Linville <[email protected]>; Zhang, Qi Z > <[email protected]>; Shepard Siegel <[email protected]>; > Ed Czeck <[email protected]>; John Miller > <[email protected]>; Igor Russkikh > <[email protected]>; Pavel Belous <[email protected]>; > Matt Peters <[email protected]>; Rasesh Mody > <[email protected]>; Shahed Shaikh <[email protected]>; Ajit > Khaparde <[email protected]>; Somnath Kotur > <[email protected]>; Chas Williams <[email protected]>; Rahul > Lakkireddy <[email protected]>; Hemant Agrawal > <[email protected]>; Marcin Wojtas <[email protected]>; Michal > Krawczyk <[email protected]>; Guy Tzalik <[email protected]>; Evgeny > Schemeilin <[email protected]>; Gagandeep Singh <[email protected]>; > John Daley <[email protected]>; Hyong Youb Kim <[email protected]>; > Gaetan Rivet <[email protected]>; Wang, Xiao W <[email protected]>; > Yang, Qiming <[email protected]>; Yigit, Ferruh > <[email protected]>; Shijith Thotton <[email protected]>; > Srisivasubramanian Srinivasan <[email protected]>; Matan Azrad > <[email protected]>; Shahaf Shuler <[email protected]>; Zyta > Szpak <[email protected]>; Liron Himi <[email protected]>; Stephen > Hemminger <[email protected]>; K. Y. Srinivasan > <[email protected]>; Haiyang Zhang <[email protected]>; Jerin > Jacob <[email protected]>; Richardson, Bruce > <[email protected]>; Andrew Rybchenko > <[email protected]>; Singh, Jasvinder > <[email protected]>; Dumitrescu, Cristian > <[email protected]>; Wiles, Keith <[email protected]>; > Maciej Czekaj <[email protected]>; Maxime Coquelin > <[email protected]>; Wang, Zhihong > <[email protected]>; Yong Wang <[email protected]>; > Burakov, Anatoly <[email protected]>; Xing, Beilei > <[email protected]>; Wu, Jingjing <[email protected]>; > [email protected] > Cc: Xu, Rosen <[email protected]>; [email protected]; Loftus, Ciara > <[email protected]>; Steven Webster <[email protected]>; > Somalapuram Amaranath <[email protected]>; > [email protected]; Sachin Saxena <[email protected]>; > Zhao1, Wei <[email protected]>; Guo, Jia <[email protected]>; Igor > Chauskin <[email protected]>; Ziyang Xuan <[email protected]>; > Xiaoyun Wang <[email protected]>; Guoyang Zhou > <[email protected]>; Min Hu (Connor) <[email protected]>; > Yisen Zhuang <[email protected]>; Alfredo Cardigliano > <[email protected]>; Jakub Grajciar <[email protected]>; Viacheslav > Ovsiienko <[email protected]>; Long Li <[email protected]>; > Martin Spinler <[email protected]>; Heinrich Kuhn > <[email protected]>; Harman Kalra <[email protected]>; > Nithin Dabilpuram <[email protected]>; Kiran Kumar K > <[email protected]>; Akhil Goyal <[email protected]>; Yigit, > Ferruh <[email protected]>; Thomas Monjalon <[email protected]> > Subject: Re: [dpdk-dev] CALL to eth PMD maintainers: complete closing of > port > > 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. > >
