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 0A53016E for ; Tue, 5 Dec 2017 12:47:11 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 4242020EBD; Tue, 5 Dec 2017 06:47:10 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Tue, 05 Dec 2017 06:47:10 -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=OUGoO3Pd6g8ndOYQDJ9Jvdu5Xs lR2Lq7tXWZLzeeBEQ=; b=H67CNYdf8CD2c2xteMVSNSiI4vlC1tl0xn+UEh+QvZ TXIMNEgC8DNyxtIgBUtfvzLoaM/yHraQ9rxIDkJuQ/RgAOgTlaKRxxkuwCO4+7Gm 3ykTF9sZseeWLGiFVwJVtlUKDZaOnzaS5UYsFCbXXQi/7vHGuW7QT4eHMaGV/9+m k= 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=OUGoO3 Pd6g8ndOYQDJ9Jvdu5XslR2Lq7tXWZLzeeBEQ=; b=WIN9v1qGjbBIlWCnrc+/YM nAMXTgIXEMsg1J4MdWBNcDAwDJD/VzTtl6nvKKZN+FkKxoweqT+tK3HkkJq5Vdpc StObbjPuZzWwmO+AhoDbJIKXYYVHMBQvCs4dtb83zh3UGIKFYj4YBjpPNRwiA0qt UWpbK+jRECVKa/E/TIBb4NbDL4r0ClwDZRVHxxQUKDzjxij0MOv0MTVXUOqWVCWh QHy4ucqEGRwDtAeH/ukpZomogzTcrXI2VNYcVxVfYkjY0Hh/NqXFyuLarDRQ1Ncd 4Ix9c9fMPRZrRaEv1T7s/kCNaMUELhw7A1Q7YDp6baabsWKIzkxvJJ/CpraBFYtA == 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 E3751240F8; Tue, 5 Dec 2017 06:47:09 -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:47:09 +0100 Message-ID: <8014002.LVodVVWTJF@xps> In-Reply-To: <2601191342CEEE43887BDE71AB9772585FAC4A12@irsmsx105.ger.corp.intel.com> References: <1511870281-15282-1-git-send-email-matan@mellanox.com> <2601191342CEEE43887BDE71AB9772585FAC4A12@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:47:11 -0000 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. 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. > 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. And anwyway, it may be interesting from an application point of view to be able to list every devices and their internal owners.