From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58]) by dpdk.org (Postfix) with ESMTP id 9B9351B33B for ; Fri, 19 Jan 2018 18:44:18 +0100 (CET) Received: from cpe-2606-a000-111b-4011-eaa3-4b92-4a68-8f24.dyn6.twc.com ([2606:a000:111b:4011:eaa3:4b92:4a68:8f24] helo=localhost) by smtp.tuxdriver.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1ecai4-0003DL-Gc; Fri, 19 Jan 2018 12:44:14 -0500 Date: Fri, 19 Jan 2018 12:43:40 -0500 From: Neil Horman To: Thomas Monjalon Cc: dev@dpdk.org, Matan Azrad , Bruce Richardson , "Ananyev, Konstantin" , Gaetan Rivet , "Wu, Jingjing" Message-ID: <20180119174340.GE9519@hmswarspite.think-freely.org> References: <20180118131017.GA1622@hmswarspite.think-freely.org> <1526278.zylApLv2LJ@xps> <20180119152742.GB9519@hmswarspite.think-freely.org> <7777073.qS0DmqPron@xps> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7777073.qS0DmqPron@xps> User-Agent: Mutt/1.9.1 (2017-09-22) X-Spam-Score: -2.9 (--) X-Spam-Status: No Subject: Re: [dpdk-dev] [PATCH v2 2/6] ethdev: add port ownership X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jan 2018 17:44:18 -0000 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. Neil