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

Thomas Monjalon thomas at monjalon.net
Tue Jan 23 18:33:51 CET 2018


23/01/2018 16:18, Ananyev, Konstantin:
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Ananyev, Konstantin
> > From: Thomas Monjalon [mailto:thomas at 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.
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.

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


More information about the dev mailing list