From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by dpdk.org (Postfix) with ESMTP id B59ECA49C for ; Sun, 21 Jan 2018 23:12:52 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Jan 2018 14:12:51 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.46,393,1511856000"; d="scan'208";a="21468546" Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.252.1.152]) ([10.252.1.152]) by FMSMGA003.fm.intel.com with ESMTP; 21 Jan 2018 14:12:49 -0800 To: Thomas Monjalon , Neil Horman Cc: Matan Azrad , "Ananyev, Konstantin" , Gaetan Rivet , "Wu, Jingjing" , dev@dpdk.org, "Richardson, Bruce" References: <2601191342CEEE43887BDE71AB9772588627DE30@irsmsx105.ger.corp.intel.com> <3919053.IPF3Pcupc4@xps> <20180119173717.GD9519@hmswarspite.think-freely.org> <1653510.Ws8EKuMe4m@xps> From: Ferruh Yigit Message-ID: <59928bab-0260-6a47-6b89-157231de4382@intel.com> Date: Sun, 21 Jan 2018 22:12:49 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <1653510.Ws8EKuMe4m@xps> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit 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: Sun, 21 Jan 2018 22:12:53 -0000 On 1/19/2018 6:10 PM, Thomas Monjalon wrote: > 19/01/2018 18:37, Neil Horman: >> On Fri, Jan 19, 2018 at 06:09:47PM +0100, Thomas Monjalon wrote: >>> 19/01/2018 15:32, Neil Horman: >>>> On Fri, Jan 19, 2018 at 03:07:28PM +0100, Thomas Monjalon wrote: >>>>> 19/01/2018 14:57, Neil Horman: >>>>>>>> I specifically pointed that out above. There is no reason an owernship record >>>>>>>> couldn't be added to the rte_eth_dev structure. >>>>>>> >>>>>>> Sorry, don't understand why. >>>>>>> >>>>>> Because, thats the resource your trying to protect, and the object you want to >>>>>> identify ownership of, no? >>>>> >>>>> No >>>>> The rte_eth_dev structure is the port representation in the process. >>>>> The rte_eth_dev_data structure is the port represenation across multi-process. >>>>> The ownership must be in rte_eth_dev_data to cover multi-process protection. >>>>> >>>> Ok. You get the idea though right? That the port representation, >>>> for some definition thereof, should embody the ownership state. >>>> Neil >>> >>> Not sure to understand your question. >>> >> There is no real question here, only confirming that we are saying the same >> thing. I misspoke when I indicated ownership information should be embodied in >> rte_eth_dev rather than its shared data. But regardless, the concept is the >> same > > Yes we agree. > And I think it is what Matan did. > The owner is in struct rte_eth_dev_data: Hi Thomas, Neil, Sorry I did not able to this thred, is discussion concluded?