From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by dpdk.org (Postfix) with ESMTP id 42EFE2A5D for ; Tue, 5 Dec 2017 12:53:38 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id BC5E920AE2; Tue, 5 Dec 2017 06:53:37 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute1.internal (MEProxy); Tue, 05 Dec 2017 06:53:37 -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=YSrEwz0WBu5carLVaACF03QClm QoN2tb+4wbL8ToE6I=; b=U7WVkc6OEun0YH+mZ6EKSrlYigVL0md8EhK7iEtr3C b90nvK7gK8j3+fu3kW2XkgYN3kCdnyzz3FieJrG/EokIcDZerA8tAnG3zr7Yv1wv riPJpk8XC/3u0HpjzFa5qFBU3xyBGcOwTTCW2u9rWCgXuCg6/cBYNG8GLxVNzTvF 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=YSrEwz 0WBu5carLVaACF03QClmQoN2tb+4wbL8ToE6I=; b=hk4hBVkl9vqXpZQFhQNX2F 23RIxMVGJRj1bmaiqttTHRyEPJwE9ovYdjlIu1QaFYVLTTVvGNAHMyEGpEyK35KU 2AU4LDcokQ605m4SZaJ0SDaSx3kV3nouvz1Au6TEG6NSgmrK/a1A0ucC/iQQMjNT 7x/b3lZzWXu3JYCrep5maIu1F79KsZf7KDoqZTs511xZFqbTzPcc6z7aRCsysTVM Ni4nvE9sCLUUG9kjE8CwN7gduQGwz0ykkNQNuJttRPwRAE62qu6TEEKyNXw5Agk7 d2Zw/vneMYqkJDmL6J0BIfM56HQntnpw48fLCxUktNbSYi5PVrpykghcIIQDAyAw == 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 61B657E56E; Tue, 5 Dec 2017 06:53:37 -0500 (EST) From: Thomas Monjalon To: "Ananyev, Konstantin" Cc: Matan Azrad , Neil Horman , =?ISO-8859-1?Q?Ga=EBtan?= Rivet , "Wu, Jingjing" , dev@dpdk.org Date: Tue, 05 Dec 2017 12:53:36 +0100 Message-ID: <2265552.PIKhXtTqDC@xps> In-Reply-To: <2601191342CEEE43887BDE71AB9772585FAC4A55@irsmsx105.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> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit X-Content-Filtered-By: Mailman/MimeDel 2.1.15 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 11:53:38 -0000 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? On every architectures?