From mboxrd@z Thu Jan  1 00:00:00 1970
From: Bruce Richardson <bruce.richardson@intel.com>
Subject: Re: [PATCH 2/5] ethdev: add port ownership
Date: Tue, 5 Dec 2017 14:56:03 +0000
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
Cc: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>,
 Matan Azrad <matan@mellanox.com>, Neil Horman <nhorman@tuxdriver.com>,
 =?iso-8859-1?Q?Ga=EBtan?= Rivet <gaetan.rivet@6wind.com>,
 "Wu, Jingjing" <jingjing.wu@intel.com>, dev@dpdk.org
To: Thomas Monjalon <thomas@monjalon.net>
Return-path: <dev-bounces@dpdk.org>
Received: from mga11.intel.com (mga11.intel.com [192.55.52.93])
 by dpdk.org (Postfix) with ESMTP id C705B1D7
 for <dev@dpdk.org>; Tue,  5 Dec 2017 15:56:07 +0100 (CET)
Content-Disposition: inline
In-Reply-To: <2265552.PIKhXtTqDC@xps>
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

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.