From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Monjalon Subject: Re: [PATCH 2/5] ethdev: add port ownership Date: Tue, 05 Dec 2017 16:49:49 +0100 Message-ID: <1577215.9bkgiOIDTU@xps> 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 Cc: Matan Azrad , Neil Horman , =?ISO-8859-1?Q?Ga=EBtan?= Rivet , "Wu, Jingjing" , dev@dpdk.org To: "Ananyev, Konstantin" 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) In-Reply-To: <2601191342CEEE43887BDE71AB9772585FAC4B54@irsmsx105.ger.corp.intel.com> List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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.