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

Thomas Monjalon thomas at monjalon.net
Fri Jan 19 18:17:51 CET 2018


19/01/2018 16:27, Neil Horman:
> On Fri, Jan 19, 2018 at 03:13:47PM +0100, Thomas Monjalon wrote:
> > 19/01/2018 14:30, Neil Horman:
> > > So it seems like the real point of contention that we need to settle here is,
> > > what codifies an 'owner'.  Must it be a specific execution context, or can we
> > > define any arbitrary section of code as being an owner?  I would agrue against
> > > the latter.
> > 
> > This is the first thing explained in the cover letter:
> > "2. The port usage synchronization will be managed by the port owner."
> > There is no intent to manage the threads synchronization for a given port.
> > It is the responsibility of the owner (a code object) to configure its
> > port via only one thread.
> > It is consistent with not trying to manage threads synchronization
> > for Rx/Tx on a given queue.
> > 
> > 
> Yes, in his cover letter, and I contend that notion is an invalid design point.
> By codifying an area of code as an 'owner', rather than an execution context,
> you're defining the notion of heirarchy, not ownership. That is to say,
> you want to codify the notion that there are top level ports that the
> application might see, and some of those top level ports are parents to
> subordinate ports, which only the parent port should access directly.  If thats
> all you want to encode, there are far easier ways to do it:
> 
> struct rte_eth_shared_data {
> 	< existing bits >
> 	struct rte_eth_port_list {
> 		struct rte_eth_port_list *children;
> 		struct rte_eth_port_list *parent;
> 	};
> };
> 
> 
> Build an api around a structure like that, so that the parent/child relationship
> is globally clear, and this would be much easier, especially if you want to
> continue asserting that the notion of synchronization/exclusion is an exercise
> left to the application.

Not only Neil.
An owner can be something else than a port.
An owner can be an app process (multi-processes).
An owner can be a library.
The intent is really to solve the generic problem of which code
is managing a port.


More information about the dev mailing list