Re: [dpdk-dev] CALL to eth PMD maintainers: complete closing of port

[Thomas Monjalon <thomas@monjalon.net>]

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.