Hi Stephen
From: Stephen Hemminger
> Sent: Sunday, July 7, 2019 7:47 PM
> To: Matan Azrad <ma...@mellanox.com>
> Cc: anatoly.bura...@intel.com; dev@dpdk.org; Stephen Hemminger
> <sthem...@microsoft.com>
> Subject: Re: [dpdk-dev] [PATCH v2] examples/client_server_mp: check port
> ownership
>
> On Sun, 7 Jul 2019 05:44:55 +0000
> Matan Azrad <ma...@mellanox.com> wrote:
>
> > > + for (count = 0; pm != 0; pm >>= 1, ++count) {
> > > + struct rte_eth_dev_owner owner;
> > > +
> > > + if ((pm & 0x1) == 0)
> > > + continue;
> > > +
> > > + if (count >= max_ports) {
> > > + printf("WARNING: requested port %u not present -
> > > ignoring\n",
> > > + count);
> > > + continue;
> > > + }
> > > + if (rte_eth_dev_owner_get(count, &owner) < 0) {
> > > + printf("ERROR: can not find port %u owner\n",
> > > count);
> >
> > What if some entity will take ownership later?
> > If you want the app will be ownership aware:
> > if you sure that you want this port to be owned by this application
> you need to take ownership on it.
> > else:
> > the port is hidden by RTE_ETH_FOREACH_DEV if it is owned by some entity.
> > see how it was done in testpmd function: port_id_is_invalid().
>
> There are no mysterious entities in DPDK.
> The only thing that can happen later is hotplug, and that will not change
> state
> of existing port.
> This model is used for all applications. The application does not take
> ownership, only device drivers do.
A long discussions were done on it.
There is an application model to take ownership as I wrote you above.
You chose in the second option - not to be ownership aware.
>From docs:
"10.4.2. Port Ownership
The Ethernet devices ports can be owned by a single DPDK entity (application,
library, PMD, process, etc). The ownership mechanism is controlled by ethdev
APIs and allows to set/remove/get a port owner by DPDK entities. Allowing this
should prevent any multiple management of Ethernet port by different entities.
Note
It is the DPDK entity responsibility to set the port owner before using it and
to manage the port usage synchronization between different threads or
processes."
> The whole portmask as command-line parameter is a bad user experience
> now, but that is a different problem.
I think, this is the problem you should solve here.
Matan
