19/01/2018 18:43, Neil Horman:
> On Fri, Jan 19, 2018 at 06:17:51PM +0100, Thomas Monjalon wrote:
> > 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.
> >
> I don't see how this precludes any part of what you just said. Define the
> rte_eth_port_list externally to the shared_data struct and allow any object
> you
> want to allocate it, then anything you want to control a heirarchy of ports
> can
> do so without issue, and the structure is far more clear than an opaque id
> that
> carries subtle semantic ordering with it.
Sorry, I don't understand. Please could you rephrase?
