Hi Jerin and Thomas BR Rongwei
> -----Original Message----- > From: Thomas Monjalon <tho...@monjalon.net> > Sent: Wednesday, February 1, 2023 16:47 > To: Andrew Rybchenko <andrew.rybche...@oktetlabs.ru>; Jerin Jacob > <jerinjac...@gmail.com> > Cc: Rongwei Liu <rongw...@nvidia.com>; dev@dpdk.org; Matan Azrad > <ma...@nvidia.com>; Slava Ovsiienko <viachesl...@nvidia.com>; Ori Kam > <or...@nvidia.com>; step...@networkplumber.org; Raslan Darawsheh > <rasl...@nvidia.com>; Ferruh Yigit <ferruh.yi...@amd.com>; > bruce.richard...@intel.com > Subject: Re: [PATCH v4 2/3] ethdev: add standby state for live migration > > External email: Use caution opening links or attachments > > > 01/02/2023 09:40, Jerin Jacob: > > On Wed, Feb 1, 2023 at 1:02 PM Andrew Rybchenko > > <andrew.rybche...@oktetlabs.ru> wrote: > > > > > > On 2/1/23 01:55, Thomas Monjalon wrote: > > > > 31/01/2023 19:14, Jerin Jacob: > > > >> On Wed, Jan 18, 2023 at 9:15 PM Rongwei Liu <rongw...@nvidia.com> > wrote: > > > >>> > > > >>> When a DPDK application must be upgraded, the traffic downtime > > > >>> should be shortened as much as possible. > > > >>> During the migration time, the old application may stay alive > > > >>> while the new application is starting and being configured. > > > >>> > > > >>> In order to optimize the switch to the new application, the old > > > >>> application may need to be aware of the presence of the new > > > >>> application being prepared. > > > >>> This is achieved with a new API allowing the user to change the > > > >>> new application state to standby and active later. > > > >>> > > > >>> The added function is trying to apply the new state to all > > > >>> probed ethdev ports. To make this API simple and easy to use, > > > >>> the same flags have to be accepted by all devices. > > > >>> > > > >>> This is the scenario of operations in the old and new applications: > > > >>> . device: already configured by the old application > > > >>> . new: start as active > > > >>> . new: probe the same device > > > >> > > > >> How to probe same device if is already bind to another application? > > > >> vfio-pci wont allow this. > > > > > > > > I missed that part. > > > > There is no way to share a VFIO device between 2 applications? > > > > > > As I understand multi-process shares an VFIO device between many > > > application. As far as I remember it is just required to pass > > > corresponding file descriptor to another application. Thanks for the comments. I missed this part when designed this feature. Per my test, vfio-pci doesn't support two primary applications using the same handle(/dev/vfio/***). We will move this back to mlx5 specific. > > > > I think, Here, it is two different primary application. > > Yes it is 2 primary applications. > > > Even if it is primary-secondary kind of case, bus or pci driver layer > > needs fixup, Currently, if we add allow list same PCI device on > > primary and secondary, the second app start will fail. > > Can we imagine passing a VFIO handle to the new application? > >
