From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id C705B1D7 for ; Tue, 5 Dec 2017 15:56:07 +0100 (CET) Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Dec 2017 06:56:06 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.45,364,1508828400"; d="scan'208";a="183859734" Received: from bricha3-mobl3.ger.corp.intel.com ([10.252.7.32]) by fmsmga005.fm.intel.com with SMTP; 05 Dec 2017 06:56:04 -0800 Received: by (sSMTP sendmail emulation); Tue, 05 Dec 2017 14:56:03 +0000 Date: Tue, 5 Dec 2017 14:56:03 +0000 From: Bruce Richardson To: Thomas Monjalon Cc: "Ananyev, Konstantin" , Matan Azrad , Neil Horman , =?iso-8859-1?Q?Ga=EBtan?= Rivet , "Wu, Jingjing" , dev@dpdk.org Message-ID: <20171205145602.GA10932@bricha3-MOBL3.ger.corp.intel.com> References: <1511870281-15282-1-git-send-email-matan@mellanox.com> <2601191342CEEE43887BDE71AB9772585FAC4A12@irsmsx105.ger.corp.intel.com> <2601191342CEEE43887BDE71AB9772585FAC4A55@irsmsx105.ger.corp.intel.com> <2265552.PIKhXtTqDC@xps> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2265552.PIKhXtTqDC@xps> Organization: Intel Research and Development Ireland Ltd. User-Agent: Mutt/1.9.1 (2017-09-22) Subject: Re: [dpdk-dev] [PATCH 2/5] 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: Tue, 05 Dec 2017 14:56:08 -0000 On Tue, Dec 05, 2017 at 12:53:36PM +0100, Thomas Monjalon wrote: > 05/12/2017 12:44, Ananyev, Konstantin: > > Just forgot to mention - I don' think it is good idea to disallow secondary process to set theowner. > > I think we all agree on that. > My initial suggestion was to use the ownership in secondary processes. > I think Matan forbid it as a first step because there is no > multi-process synchronization currently. > > > Let say in secondary process I have few tap/ring/pcap devices. > > Why it shouldn't be allowed to unite them under bonding device and make that device to own them? > > That's why I think get/set owner better to be atomic. > > If the owner is just a pointer - in that case get operation will be atomic by nature, > > set could be implemented just by CAS. > > It would be perfect. > Can we be sure that the atomic will work perfectly on shared memory? The sharing of memory is an OS-level construct in managing page tables, more than anything else. For atomic operations, a memory address is a memory address, whether it is shared or private to a process. > On every architectures? All architectures should have an atomic compare-and-set equivalent operation for it's native pointer size. In the unlikely case we have to support one that doesn't, we can special-case that in some other way.