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 2F1D11B32E for ; Fri, 19 Jan 2018 16:28:20 +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 1ecYaU-0001yc-Jp; Fri, 19 Jan 2018 10:28:16 -0500 Date: Fri, 19 Jan 2018 10:27:42 -0500 From: Neil Horman To: Thomas Monjalon Cc: dev@dpdk.org, Matan Azrad , Bruce Richardson , "Ananyev, Konstantin" , Gaetan Rivet , "Wu, Jingjing" Message-ID: <20180119152742.GB9519@hmswarspite.think-freely.org> References: <20180118131017.GA1622@hmswarspite.think-freely.org> <20180119133019.GB5342@hmswarspite.think-freely.org> <1526278.zylApLv2LJ@xps> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1526278.zylApLv2LJ@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 15:28:20 -0000 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. Neil