From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by dpdk.org (Postfix) with ESMTP id 1B99D1B2CA for ; Fri, 19 Jan 2018 18:18:28 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id AE4AA20C39; Fri, 19 Jan 2018 12:18:27 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Fri, 19 Jan 2018 12:18:27 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=mesmtp; bh=45rM22TjiPkVVrWdhtD5aH2Xz4 G/9+kGKt7iIbkL0+s=; b=hYPti2HRl2MT8b6N45GJlLK8HAQSObnI071vgNP4H8 3h+E2S6e0tXb/g8iFxKYQ2YW7+Ei08VnVnP+9OsQTLBfWnEYRfIo5hx6FxEzyLm5 z6S6AOnjSzBXZgIpwCzRGe0HmSkBHEtcVRGjhJTgaYMYGmXW15nOK5QM3HZnSgUG I= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=45rM22 TjiPkVVrWdhtD5aH2Xz4G/9+kGKt7iIbkL0+s=; b=PPgIqO3kgZ1TEq6l+b3/Ic M0SEdRElz7q+UOMrEmb11s3In9osjPUElT50Zmju5ZHe87Y+LgT8rfvtuY4tLCLG 9VWfpfT+ifvvJo7yV3veP9YRfqG9ViLiMeOEWSaWQ99CmssGgnjZDnP1cgGom2ga jaLVw0K4tKp5INrSIXU4ql08KhRJT2mjcMW2GRNkUAZoHUy1Wp+XjV9EKkCoy+5u OKnOy2qRjj/AoK0NId73W1Hxk27fBQHUgHWygzuQ8Hqw5eeWbZIkqeBLH8QdXsb2 hX9NSBUC1WHbO94fkmwyg1Ymdp8FDB+vXgItoWEZc6OWuWuHryLtfG5rAXPvnjRQ == X-ME-Sender: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 559A3240DE; Fri, 19 Jan 2018 12:18:27 -0500 (EST) From: Thomas Monjalon To: Neil Horman Cc: dev@dpdk.org, Matan Azrad , Bruce Richardson , "Ananyev, Konstantin" , Gaetan Rivet , "Wu, Jingjing" Date: Fri, 19 Jan 2018 18:17:51 +0100 Message-ID: <7777073.qS0DmqPron@xps> In-Reply-To: <20180119152742.GB9519@hmswarspite.think-freely.org> References: <20180118131017.GA1622@hmswarspite.think-freely.org> <1526278.zylApLv2LJ@xps> <20180119152742.GB9519@hmswarspite.think-freely.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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:18:28 -0000 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.