Re: [dpdk-dev] [PATCH v3 7/7] app/testpmd: adjust ethdev port ownership

[Thomas Monjalon <thomas@monjalon.net>]

25/01/2018 12:15, Ananyev, Konstantin:
> Hi everyone,
> 
> > 
> > 25/01/2018 10:36, Matan Azrad:
> > > Gaetan, Konstantin, Thomas
> > >
> > > Any response to my suggestion below?
> > >
> > > From: Matan Azrad
> > > > Suggestion:
> > > >
> > > > 2 system owners.
> > > > APP_OWNER - 1.
> > > > NO_OWNER - 0.
> > > >
> > > > And allowing for more owners as now.
> > > >
> > > > 1. Every port creation will set the owner for NO_OWNER (as now).
> > > > 2. There is option for all dpdk entities to take owner of  NO_OWNER ports all
> > > > the time(as now).
> > > > 3. In some point in the end of EAL init: set all the NO_OWNER to
> > > > APP_OWNER(for V6).
> 
> What will happen if we have 2 (or more process) sharing the same device?
> How we will distinguish what APP_OWNER we are talking about?
> Shouldn't default_owner be unique per process?

Yes, good point!
Each application process should be considered a different owner
by default.

> > > > 4. Change the old iterator to iterate over APP_OWNER ports(for V6).
> 
> If I get it right it means no changes in tetpmd, correct?

It is my understanding yes.

> > > > What do you think?
> > 
> > Reminder for everybody: there is no issue if no hotplug.
> > There is a race condition with hotplug.
> > Hotplug is not managed by EAL yet, but there is a temporary hotplug
> > management in failsafe.
> > So until now, the issue is seen only with hotplug in failsafe.
> > 
> > Your suggestion makes no change for applications,
> > and fix the ownership issue for failsafe.
> > And later, if an application wants to support generic hotplug properly
> > (when it will be generally available in DPDK),
> > the application should use the ownership API.
> > Right?
> > 
> > I think it is a good compromise.
> 
> I still think it would be good if future hotplug support will be transparent
> to existing apps (no/minimal changes).
> But I suppose we can discuss it later, when will have hotplug patches.

It cannot be really transparent.
If an application is based on port detection at init, it has to be changed
to decide how to handle new ports.
That's why I introduced the new events for ethdev notification callback.