>
> 23/01/2018 16:18, Ananyev, Konstantin:
> > From: dev [mailto:dev-boun...@dpdk.org] On Behalf Of Ananyev, Konstantin
> > > From: Thomas Monjalon [mailto:tho...@monjalon.net]
> > > > 23/01/2018 14:34, Ananyev, Konstantin:
> > > > > If that' s the use case, then I think you need to set device
> > > > > ownership at creation time -
> > > > > inside dev_allocate().
> > > > > Again that would avoid such racing conditions inside testpmd.
> > > >
> > > > The devices must be allocated at a low level layer.
> > >
> > > No one arguing about that.
> > > But we can provide owner id information to the low level.
>
> Sorry, you did not get it.
Might be.
> We cannot provide owner id at the low level
> because it is not yet decided who will be the owner
> before the port is allocated.
Why is that?
What prevents us decide who will manage that device *before* allocating port of
it?
IMO we do have all needed information at that stage.
>
> > > > When a new device appears (hotplug), an ethdev port should be allocated
> > > > automatically if it passes the whitelist/blacklist policy test.
> > > > Then we must decide who will manage this device.
> > > > I suggest notifying the DPDK libs first.
> > > > So a DPDK lib or PMD like failsafe can have the priority to take the
> > > > ownership in its notification callback.
> > >
> > > Possible, but seems a bit overcomplicated.
> > > Why not just:
> > >
> > > Have a global variable process_default_owner_id, that would be init once
> > > at startup.
> > > Have an LTS variable default_owner_id.
> > > It will be used by rte_eth_dev_allocate() caller can set dev->owner_id at
> > > creation time,
> > > so port allocation and setting ownership - will be an atomic operation.
> > > At the exit rte_eth_dev_allocate() will always reset default_owner_id=0:
> > >
> > > rte_eth_dev_allocate(...)
> > > {
> > > lock(owner_lock);
> > > <allocate_port>
> > > owner = RTE_PER_LCORE(default_owner_id);
> > > if (owner == 0)
> > > owner = process_default_owner_id;
> > > set_owner(port, ..., owner);
> > > unlock(owner_lock);
> > > RTE_PER_LCORE(default_owner_id) = 0;
> >
> > Or probably better to leave default_owner_id reset to the caller.
> > Another thing - we can use same LTS variable in all control ops to
> > allow/disallow changing of port configuration based on ownership.
> > Konstantin
> >
> > > }
> > >
> > > So callers who don't need any special ownership - don't need to do
> > > anything.
> > > Special callers (like failsafe) can set default_owenr_id just before
> > > calling hotplug
> > > handling routine.
>
> No, hotplug will not be a routine.
> I am talking about real hotplug, like a device which appears in the VM.
> This new device must be handled by EAL and probed automatically if
> comply with whitelist/blacklist policy given by the application or user.
> Real hotplug is asynchronous.
By 'asynchronous' here you mean it would be handled in the EAL interrupt thread
or something different?
Anyway, I suppose you do need a function inside DPDK that will do the actual
work in response
on hotplug event, right?
That's what I refer to as 'hotplug routine' above.
> We will just receive notifications that it appeared.
>
> Note: there is some temporary code in failsafe to manage some hotplug.
> This code must be removed when it will be properly handled in EAL.
Ok, if it is just a temporary code, that would be removed soon -
then it definitely seems wrong to modify tespmd (or any other user app)
to comply with that temporary solution.
Konstantin
