10/05/2018 22:33, Stephen Hemminger:
> On Wed, 9 May 2018 11:43:33 +0200
> Thomas Monjalon <tho...@monjalon.net> wrote:
>
> >
> > +struct rte_eth_dev *
> > +rte_eth_dev_allocated(const char *name)
> > +{
> > + struct rte_eth_dev *ethdev;
> > +
> > + rte_eth_dev_shared_data_prepare();
> > +
> > + rte_spinlock_lock(&rte_eth_dev_shared_data->ownership_lock);
> > +
> > + ethdev = rte_eth_dev_allocated_lock_free(name);
> > +
> > + rte_spinlock_unlock(&rte_eth_dev_shared_data->ownership_lock);
> > +
> > + return ethdev;
> > +}
> > +
>
> Not sure about this. The code it self is correct, but it creates
> a racy semantic.
>
> If caller doesn't already hold a lock then there is no guarantee that
> the device returned won't be destroyed by some other thread
It is an old high level design decision in DPDK:
We do not hold a lock during the whole life of a port.
So it is the application responsibility to not mess its own ports.
The consequence is that one port must be managed by only one thread.
We can discuss the original thread design but it is out of the
scope of this patchset.
> or that the name was just allocated by some other process.
It does not say which process allocated the port, yes.
But the name is unique among processes.
So the process knows for sure what to do with the port having this name.
