From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by dpdk.org (Postfix) with ESMTP id EA4391C00 for ; Tue, 5 Dec 2017 16:49:50 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 55E2B21B22; Tue, 5 Dec 2017 10:49:50 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Tue, 05 Dec 2017 10:49:50 -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=A1GLfsGVKGCNU4qfhBtOhZSwHj 8n91TKfH/nXZcAZco=; b=nE2UbNK4K3ecqR8qSW5HmflT733Q6SODE8HplFuSdw xlzTobm8Z/zeebX9MVVxpU1Q3CEK4IaEp3WbtBW0aV9rof9J/OUSy6amyk8AcVMU dvzqvxYhBwlEDc6kR0rAFMzD8MQkZHxLDDl73xqPmTd+WiyOjpl7MvmqM1WZAb4E w= 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=A1GLfs GVKGCNU4qfhBtOhZSwHj8n91TKfH/nXZcAZco=; b=aAydVOjcFrlmuyTadhCN/p JWsYXRKHR883ef1M6PbrE6jrDNFt67270OCYYLH/oRftgdRxdB4juZhScJMxp2gw iqem3Bzc4PClXTAzBA6CrdmZRLF9AZQETmyuXeK0hChbEIxJz2nu465ztVVx2vif R5VW6CZQeRPwG4UDNNrZRBsUIf5/bmE1hD3Dy1pG5r8beh+eotk///QYecqeLyVg yhGUGDLtwHt2kXJW3U5KoQ+YhU9YD6HffTXucUrBfs9OO3XUZEau9pWxzXdY4J4i ObD7zIOardrd9pcRt6JoGgjBNYhO4pKFXYsh7zKeHG3r9+F8RcXeyxjdKmD6458w == 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 DCB9A2469F; Tue, 5 Dec 2017 10:49:49 -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 16:49:49 +0100 Message-ID: <1577215.9bkgiOIDTU@xps> In-Reply-To: <2601191342CEEE43887BDE71AB9772585FAC4B54@irsmsx105.ger.corp.intel.com> References: <1511870281-15282-1-git-send-email-matan@mellanox.com> <8014002.LVodVVWTJF@xps> <2601191342CEEE43887BDE71AB9772585FAC4B54@irsmsx105.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" 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 15:49:51 -0000 05/12/2017 16:13, Ananyev, Konstantin: > > Hi Thomas, > > > Hi, > > > I will give my view on locking and synchronization in a different email. > > Let's discuss about the API here. > > > 05/12/2017 12:12, Ananyev, Konstantin: > > >> From: Matan Azrad [mailto:matan@mellanox.com] > >> > From: Ananyev, Konstantin [mailto:konstantin.ananyev@intel.com] > > > > > > If the goal is just to have an ability to recognize is that device is managed by > > > > > another device (failsafe, bonding, etc.), then I think all we need is a pointer > > > > > to rte_eth_dev_data of the owner (NULL would mean no owner). > > > > > > > > I think string is better than a pointer from the next reasons: > > > > 1. It is more human friendly than pointers for debug and printing. > > > > > > We can have a function that would take an owner pointer and produce nice > > > pretty formatted text explanation: "owned by fail-safe device at port X" or so. > > > I don't think it is possible or convenient to have such function. > > Why do you think it is not possible? Because of applications being the owner (discussion below). > > Keep in mind that the owner can be an application thread. > > If you prefer using a single function pointer (may help for > > atomic implementation), we can allocate an owner structure containing > > a name as a string to identify the owner in human readable format. > > Then we just have to set the pointer of this struct to rte_eth_dev_data. > > Basically you'd like to have an ability to set something different then > pointer to rte_eth_dev_data as an owner, right? No, it can be a pointer, or an id, I don't care. > I think this is possible too, just not sure it will useful. > > > > What I meant - this api to set/get ownership should be sort of internal to ethdev layer. > > > Let say it would be used for failsafe/bonding (any other compound) device that needs > > > to own/manage several low-level devices. > > > So in normal situation user wouldn't need to use that API directly at all. > > > Again, the application may use this API to declare its ownership. > > Could you explain that a bit: what would mean 'application declares an ownership on device'? > Does it mean that no other application will be allowed to do any control op on that device > till application will clear its ownership? > I.E. make sure that at each moment only one particular thread can modify device configuration? > Or would it be totally informal and second application will be free to ignore it? It is an information. It will avoid a library taking ownership on a port controlled by the app. > If it will be the second one - I personally don't see much point in it. > If it the first one - then simplest and most straightforward way would be - > introduce a mutex (either per device or just per whole rte_eth_dev[]) and force > each control op to grab it at entrance release at exit. No, a mutex does not provide any information. > > And anwyway, it may be interesting from an application point of view > > to be able to list every devices and their internal owners. > > Yes sure application is free to call 'get' to retrieve information etc. > What I am saying for normal operation - application don't have to call that API. > I.E. - we don't need to change testpmd, etc. apps because that API was introduced. Yes the ports can stay without any owner if the application does not fill it.