From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by dpdk.org (Postfix) with ESMTP id 1B1AE1B026 for ; Tue, 23 Jan 2018 18:34:33 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 9640120C81; Tue, 23 Jan 2018 12:34:31 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Tue, 23 Jan 2018 12:34:31 -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=OF0SzNeOY3r9t0RNpgkLlAVyty H0psWgFOTmNR2WJz8=; b=iUTgxVbw/1Kta346mwER7r86OfByxLkcoXW45OrVBT E82itdguKNqBxCAG//W9EdswTLKe6+ja8mWNhal9hhMW0uV9sJuaWQaONhss7wKU BTLoCRt7ZsHslPlWQf85clYo2tpbnavmcHBFQrlSfSTW1p9YkI958gQDT32Uauea g= 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=OF0SzN eOY3r9t0RNpgkLlAVytyH0psWgFOTmNR2WJz8=; b=MbRS/PVk7Tb8Ha1FE7Tgdl j9oVS0UbSUT17CeZ/hFhFVLYh4nTO0BEN8nky8xq9J6okM0JbUBMpkyiAfT8Xjnn 2pTHHv2uzzSm+81dFPn3wKRiqLs/kEe4cfrah/UzniyLQNZ3TBPd/Xx7leg+NWzU /vUOk94G7+mkdBgZ3lh/a+fnEPQTPbWB/haO6g8uaqTkw980rZ2ZRQcIWJ3k6hpP uYkURFP74IMT0AGe68cHsOno9CHxMTnhGfg1MoAG7LiVulex1JCUoh0jY4fwU2vw UVdCv3S6X+KMenkYB3dqtwy4RSOvES9giRAq0FP0c1fqb0E/H2FpR0Xk+IRcF/Tg == 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 565B2246F4; Tue, 23 Jan 2018 12:34:31 -0500 (EST) From: Thomas Monjalon To: "Ananyev, Konstantin" Cc: Matan Azrad , =?ISO-8859-1?Q?Ga=EBtan?= Rivet , "Wu, Jingjing" , dev@dpdk.org, Neil Horman , "Richardson, Bruce" Date: Tue, 23 Jan 2018 18:33:51 +0100 Message-ID: <3663694.426ICJToDY@xps> In-Reply-To: <2601191342CEEE43887BDE71AB9772588628270E@irsmsx105.ger.corp.intel.com> References: <1515318351-4756-1-git-send-email-matan@mellanox.com> <2601191342CEEE43887BDE71AB977258862826E0@irsmsx105.ger.corp.intel.com> <2601191342CEEE43887BDE71AB9772588628270E@irsmsx105.ger.corp.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v3 7/7] app/testpmd: adjust ethdev 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, 23 Jan 2018 17:34:33 -0000 23/01/2018 16:18, Ananyev, Konstantin: > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Ananyev, Konstantin > > From: Thomas Monjalon [mailto:thomas@monjalon.net] > > > 23/01/2018 14:34, Ananyev, Konstantin: > > > > If that' s the use case, then I think you need to set device ownership at creation time - > > > > inside dev_allocate(). > > > > Again that would avoid such racing conditions inside testpmd. > > > > > > The devices must be allocated at a low level layer. > > > > No one arguing about that. > > But we can provide owner id information to the low level. Sorry, you did not get it. We cannot provide owner id at the low level because it is not yet decided who will be the owner before the port is allocated. > > > When a new device appears (hotplug), an ethdev port should be allocated > > > automatically if it passes the whitelist/blacklist policy test. > > > Then we must decide who will manage this device. > > > I suggest notifying the DPDK libs first. > > > So a DPDK lib or PMD like failsafe can have the priority to take the > > > ownership in its notification callback. > > > > Possible, but seems a bit overcomplicated. > > Why not just: > > > > Have a global variable process_default_owner_id, that would be init once at startup. > > Have an LTS variable default_owner_id. > > It will be used by rte_eth_dev_allocate() caller can set dev->owner_id at creation time, > > so port allocation and setting ownership - will be an atomic operation. > > At the exit rte_eth_dev_allocate() will always reset default_owner_id=0: > > > > rte_eth_dev_allocate(...) > > { > > lock(owner_lock); > > > > owner = RTE_PER_LCORE(default_owner_id); > > if (owner == 0) > > owner = process_default_owner_id; > > set_owner(port, ..., owner); > > unlock(owner_lock); > > RTE_PER_LCORE(default_owner_id) = 0; > > Or probably better to leave default_owner_id reset to the caller. > Another thing - we can use same LTS variable in all control ops to > allow/disallow changing of port configuration based on ownership. > Konstantin > > > } > > > > So callers who don't need any special ownership - don't need to do anything. > > Special callers (like failsafe) can set default_owenr_id just before calling hotplug > > handling routine. No, hotplug will not be a routine. I am talking about real hotplug, like a device which appears in the VM. This new device must be handled by EAL and probed automatically if comply with whitelist/blacklist policy given by the application or user. Real hotplug is asynchronous. We will just receive notifications that it appeared. Note: there is some temporary code in failsafe to manage some hotplug. This code must be removed when it will be properly handled in EAL.