> -----Original Message----- > From: Thomas Monjalon <[email protected]> > Sent: Tuesday, September 29, 2020 07:14 > To: [email protected] > Cc: Yigit, Ferruh <[email protected]>; [email protected]; > Shijith Thotton > <[email protected]>; Srisivasubramanian Srinivasan > <[email protected]>; Heinrich Kuhn > <[email protected]>; Alfredo Cardigliano <[email protected]>; > Liron Himi > <[email protected]>; Ray Kinsella <[email protected]>; Neil Horman > <[email protected]>; John W. > Linville <[email protected]>; Loftus, Ciara <[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]>; > Steven Webster > <[email protected]>; Matt Peters <[email protected]>; > Somalapuram Amaranath > <[email protected]>; Rasesh Mody <[email protected]>; Shahed Shaikh > <[email protected]>; Ajit > Khaparde <[email protected]>; Somnath Kotur > <[email protected]>; Chas Williams > <[email protected]>; Wei Hu (Xavier) <[email protected]>; Rahul Lakkireddy > <[email protected]>; Hemant Agrawal <[email protected]>; > Sachin Saxena > <[email protected]>; Guo, Jia <[email protected]>; Wang, Haiyue > <[email protected]>; > Marcin Wojtas <[email protected]>; Michal Krawczyk <[email protected]>; Guy > Tzalik <[email protected]>; > Evgeny Schemeilin <[email protected]>; Igor Chauskin <[email protected]>; > Gagandeep Singh > <[email protected]>; John Daley <[email protected]>; Hyong Youb Kim > <[email protected]>; Gaetan Rivet > <[email protected]>; Wang, Xiao W <[email protected]>; Ziyang Xuan > <[email protected]>; Xiaoyun > Wang <[email protected]>; Guoyang Zhou <[email protected]>; > Min Hu (Connor) > <[email protected]>; Yisen Zhuang <[email protected]>; Xing, Beilei > <[email protected]>; Wu, > Jingjing <[email protected]>; Yang, Qiming <[email protected]>; Jakub > Grajciar > <[email protected]>; Matan Azrad <[email protected]>; Shahaf Shuler > <[email protected]>; Viacheslav > Ovsiienko <[email protected]>; Zyta Szpak <[email protected]>; Stephen > Hemminger > <[email protected]>; K. Y. Srinivasan <[email protected]>; Haiyang > Zhang <[email protected]>; > Long Li <[email protected]>; Martin Spinler <[email protected]>; Tetsuya > Mukawa > <[email protected]>; Harman Kalra <[email protected]>; Jerin Jacob > <[email protected]>; Nithin > Dabilpuram <[email protected]>; Kiran Kumar K > <[email protected]>; Akhil Goyal > <[email protected]>; Richardson, Bruce <[email protected]>; Singh, > Jasvinder > <[email protected]>; Dumitrescu, Cristian > <[email protected]>; Wiles, Keith > <[email protected]>; Maxime Coquelin <[email protected]>; Xia, > Chenbo > <[email protected]>; Wang, Zhihong <[email protected]>; Yong Wang > <[email protected]> > 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 <[email protected]> > Cc: Srisivasubramanian Srinivasan <[email protected]> > Cc: Heinrich Kuhn <[email protected]> > Cc: Alfredo Cardigliano <[email protected]> > > Signed-off-by: Thomas Monjalon <[email protected]> > Reviewed-by: Liron Himi <[email protected]> > ---
> 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 <[email protected]> > 2.28.0
