From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by dpdk.org (Postfix) with ESMTP id 0E4F31AEEE for ; Wed, 6 Dec 2017 10:22:52 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id AFA4C20B1C; Wed, 6 Dec 2017 04:22:51 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute1.internal (MEProxy); Wed, 06 Dec 2017 04:22:51 -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=rh7Skmjt7tPZxcFOaEDARnrYjt 3PdyIRAzyxKFkkWSg=; b=g0kIXXHIOUprGTiDndWu0Q1aD9NwlcrPaak2AYv7Pg sKLsxq/+WTsrG69+0y7iFbMmQUunujfXN0fvPV75X37/VIqsrCTd47rDgieU08sE OMcB9NWvNTRmiJ5GE1xLCDa111/tzZ/ALrwfPUnDiMGmG2Tl9wknT+3Haob0VgOE E= 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=rh7Skm jt7tPZxcFOaEDARnrYjt3PdyIRAzyxKFkkWSg=; b=W/P2IF4HejhLW/pA2Egw5a NwY6pINgcsxnArpmFdxuNj7EviwmXti1Bqmdi5Ucd+IADtkmTbfsThtveXlti5d5 b4iQYnpT9gDna+IwJzmJ7jMGA0+VDdGjdS46yWj+YzuOUVt/r7LAbbFEbY5DvsvQ xImr2YYzCMOFR27rVMYyWT/eZkTK0LgJ/sW0Pfbk/FbCru3r10odqtmbUaHTOxRj vHK6PqWlXxjLROXps3k/bjLVHtaju4SEyIBnFvcLkhSOT2wt7mAGiTmR03AhwJSU 3Vo64O6xbyHqkf2c7XCFQiIZVDY51Tbbo5Y4pYRPmAO8cQOUlfOSfkSctoIFJGQw == 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 448727E6BC; Wed, 6 Dec 2017 04:22:51 -0500 (EST) From: Thomas Monjalon To: "Ananyev, Konstantin" Cc: Matan Azrad , "Neil Horman (nhorman@tuxdriver.com)" , "Wu, Jingjing" , =?ISO-8859-1?Q?Ga=EBtan?= Rivet , dev@dpdk.org Date: Wed, 06 Dec 2017 10:22:50 +0100 Message-ID: <2229310.0u3kHnN1SQ@xps> In-Reply-To: <2601191342CEEE43887BDE71AB9772585FAC50B8@irsmsx105.ger.corp.intel.com> References: <2601191342CEEE43887BDE71AB9772585FAC50B8@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: Wed, 06 Dec 2017 09:22:52 -0000 06/12/2017 01:40, Ananyev, Konstantin: > From: Thomas Monjalon [mailto:thomas@monjalon.net] > > 05/12/2017 16:13, Ananyev, Konstantin: > > > > 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. > > My question was about a pointer to a specific struct: rte_eth_dev_data. > As I understand you want it to be a pointer to something else? > Probably to some new struct rte_eth_dev_owner or so... I have no strong opinion. The requirement is to identify owners with something unique, and to be able to print a pretty name. > > > 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. > > Ok, let's step back a bit. > As I can see there are 2 separate issues/design choices inside rte_ethdev :) : > 1) control API is not MT safe - at any given moment 2 (or more) threads (/processes) > can try to change config of a given device. > Right now we leave that sync effort to the upper layer. > 2) Even with the same thread 2 (or more) DPDK entities (high level PMD/third party lib, etc.) > can try to manage the same device. > I.E. the device can be managed by bonding device, but application mistakenly > can try to manage it on its own instead of relying on the bonding device to do so. > Again right now we leave it up to the upper layer to keep track which device is managed > by what DPDK entity. > > So what problem are you guys trying to solve with your patch? > Is it 1) or 2) below or might be something else? We try to solve 2) By solving 2), the issue 1) is slightly different: Thread safety with control API will become the responsibility of the DPDK entity (app or lib) which owns the port. Hope it is clear now, thanks for the brainstorming.