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. > > 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?