[dpdk-dev] [PATCH 2/5] ethdev: add port ownership

[Thomas Monjalon]

06/12/2017 01:40, Ananyev, Konstantin:
> From: Thomas Monjalon [mailto:thomas at monjalon.net]
> > 05/12/2017 16:13, Ananyev, Konstantin:

> > > > Keep in mind that the owner can be an application thread.
> > > > If you prefer using a single function pointer (may help for
> > > > atomic implementation), we can allocate an owner structure containing
> > > > a name as a string to identify the owner in human readable format.
> > > > Then we just have to set the pointer of this struct to rte_eth_dev_data.
> > >
> > > Basically you'd like to have an ability to set something different then
> > > pointer to rte_eth_dev_data as an owner, right?
> > 
> > No, it can be a pointer, or an id, I don't care.
> 
> My question was about a pointer to a specific struct: rte_eth_dev_data.
> As I understand you want it to be a pointer to something else?
> Probably to some new struct rte_eth_dev_owner or so...

I have no strong opinion.
The requirement is to identify owners with something unique,
and to be able to print a pretty name.


> > > I think this is possible too, just not sure it will useful.
> > >
> > > > > What I meant - this api to set/get ownership should be sort of internal to ethdev layer.
> > > > > Let say it would be used for failsafe/bonding (any other compound) device that needs
> > > > > to own/manage several low-level devices.
> > > > > So in normal situation user wouldn't need to use that API directly at all.
> > >
> > > > Again, the application may use this API to declare its ownership.
> > >
> > > Could you explain that a bit: what would mean 'application declares an ownership on device'?
> > > Does it mean that no other application will be allowed to do any control op on that device
> > > till application will clear its ownership?
> > > I.E. make sure that at each moment only one particular thread can modify device configuration?
> > > Or would it be totally informal and second application will be free to ignore it?
> > 
> > It is an information.
> > It will avoid a library taking ownership on a port controlled by the app.
> 
> Ok, let's step back a bit.
> As I can see there are 2 separate issues/design choices inside rte_ethdev :)  :
> 1) control API is not MT safe - at any given moment 2 (or more) threads (/processes)
>     can try to change config of a given device.
>    Right now we leave that sync effort to the upper layer.
> 2) Even with the same thread 2 (or more) DPDK entities (high level PMD/third party lib, etc.)
>     can try to manage the same device.
>    I.E. the device can be managed by bonding device, but application mistakenly
>     can try to manage it on its own instead of relying on the bonding device to do so.
>    Again right now we leave it up to the upper layer to keep track which device is managed
>    by what DPDK entity.
> 
> So what problem are you guys trying to solve with your patch?
> Is it 1) or 2) below or might be something else?

We try to solve 2)

By solving 2), the issue 1) is slightly different:
Thread safety with control API will become the responsibility
of the DPDK entity (app or lib) which owns the port.

Hope it is clear now, thanks for the brainstorming.