From: Thomas Monjalon <thomas@monjalon.net>
To: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>
Cc: "Matan Azrad" <matan@mellanox.com>,
"Neil Horman (nhorman@tuxdriver.com)" <nhorman@tuxdriver.com>,
"Wu, Jingjing" <jingjing.wu@intel.com>,
"Gaëtan Rivet" <gaetan.rivet@6wind.com>,
dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH 2/5] ethdev: add port ownership
Date: Wed, 06 Dec 2017 10:22:50 +0100 [thread overview]
Message-ID: <2229310.0u3kHnN1SQ@xps> (raw)
In-Reply-To: <2601191342CEEE43887BDE71AB9772585FAC50B8@irsmsx105.ger.corp.intel.com>
06/12/2017 01:40, Ananyev, Konstantin:
> From: Thomas Monjalon [mailto:thomas@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.
next prev parent reply other threads:[~2017-12-06 9:22 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-06 0:40 Ananyev, Konstantin
2017-12-06 9:22 ` Thomas Monjalon [this message]
-- strict thread matches above, loose matches on Subject: below --
2017-11-28 11:57 [dpdk-dev] [PATCH 0/5] ethdev: Port ownership Matan Azrad
2017-11-28 11:57 ` [dpdk-dev] [PATCH 2/5] ethdev: add port ownership Matan Azrad
2017-11-30 12:36 ` Neil Horman
2017-11-30 13:24 ` Gaëtan Rivet
2017-11-30 14:30 ` Matan Azrad
2017-11-30 15:09 ` Gaëtan Rivet
2017-11-30 15:43 ` Matan Azrad
2017-12-01 12:09 ` Neil Horman
2017-12-03 8:04 ` Matan Azrad
2017-12-03 11:10 ` Ananyev, Konstantin
2017-12-03 13:46 ` Matan Azrad
2017-12-04 16:01 ` Neil Horman
2017-12-04 18:10 ` Matan Azrad
2017-12-04 22:30 ` Neil Horman
2017-12-05 6:08 ` Matan Azrad
2017-12-05 10:05 ` Bruce Richardson
2017-12-08 11:35 ` Thomas Monjalon
2017-12-08 12:31 ` Neil Horman
2017-12-21 17:06 ` Thomas Monjalon
2017-12-21 17:43 ` Neil Horman
2017-12-21 19:37 ` Matan Azrad
2017-12-21 20:14 ` Neil Horman
2017-12-21 21:57 ` Matan Azrad
2017-12-22 14:26 ` Neil Horman
2017-12-23 22:36 ` Matan Azrad
2017-12-29 16:56 ` Neil Horman
2017-12-05 19:26 ` Neil Horman
2017-12-08 11:06 ` Thomas Monjalon
2017-12-05 11:12 ` Ananyev, Konstantin
2017-12-05 11:44 ` Ananyev, Konstantin
2017-12-05 11:53 ` Thomas Monjalon
2017-12-05 14:56 ` Bruce Richardson
2017-12-05 14:57 ` Ananyev, Konstantin
2017-12-05 11:47 ` Thomas Monjalon
2017-12-05 15:13 ` Ananyev, Konstantin
2017-12-05 15:49 ` Thomas Monjalon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2229310.0u3kHnN1SQ@xps \
--to=thomas@monjalon.net \
--cc=dev@dpdk.org \
--cc=gaetan.rivet@6wind.com \
--cc=jingjing.wu@intel.com \
--cc=konstantin.ananyev@intel.com \
--cc=matan@mellanox.com \
--cc=nhorman@tuxdriver.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).