> -----Original Message----- > From: Ferruh Yigit <ferruh.yi...@amd.com> > Sent: Friday, July 5, 2024 13:29 > To: Stephen Hemminger <step...@networkplumber.org>; Maayan Kashani > <mkash...@nvidia.com> > Cc: dev@dpdk.org; Dariusz Sosnowski <dsosnow...@nvidia.com>; Raslan > Darawsheh <rasl...@nvidia.com>; Aman Singh <aman.deep.si...@intel.com>; > Yuying Zhang <yuying.zh...@intel.com> > Subject: Re: [PATCH] app/testpmd: support retrying device stop > > On 6/3/2024 6:09 PM, Stephen Hemminger wrote: > > On Sun, 2 Jun 2024 13:30:35 +0300 > > Maayan Kashani <mkash...@nvidia.com> wrote: > > > >> From: Dariusz Sosnowski <dsosnow...@nvidia.com> > >> > >> In some cases rte_eth_dev_stop() can fail with EBUSY error code > >> meaning that port cannot be stopped, because of other resources > >> referencing this port and port must be stopped again after these resources > >> are > freed. > >> > >> This patch adds handling of EBUSY error code on port stop to testpmd. > >> > >> Signed-off-by: Dariusz Sosnowski <dsosnow...@nvidia.com> > > > > What causes EBUSY. Seems like a driver bug or a test scenario problem. > > You can't expect every DPDK application to retry. > > > > 'rte_eth_dev_stop()' returning EBUSY anticipates this kind of usage already. > > But I also agree we should avoid propagating driver issues to the > application, that > is why it is better to clarify motivation of this patch, why specific driver > returns > EBUSY on stop.
Agreed regarding not propagating it to application. Currently mlx5 PMD can return EBUSY because of a limitation in the PMD, regarding ordering of start/stop operations of representor ports (http://git.dpdk.org/dpdk/tree/drivers/net/mlx5/mlx5_trigger.c#n1417). We should eventually resolve that limitation in PMD. I think we can drop this patch. Best regards, Dariusz Sosnowski
