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 8B3781B48A for ; Thu, 4 Oct 2018 16:25:37 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id D064D21D06; Thu, 4 Oct 2018 10:25:36 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Thu, 04 Oct 2018 10:25:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=mesmtp; bh=GD8o/7917JVGltCyPsNPHvD6aFYE5/lbbsMaBwuPZvs=; b=eAqgZov9zL83 xSenpLzN0ZWzNFOzgxCuXIISluDW3/II8sK8nyLcppJfDxA8nCfV27bPxdWUm7FK e1qXj/Fg0MCzc+ENgsWcdlENPh7ix7kVHPqaBiR6efH+7n++rjOhd0W0y40F4d94 nQGoI/2USfTb87Gog1pAGOgx6V0/hgY= 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-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=GD8o/7917JVGltCyPsNPHvD6aFYE5/lbbsMaBwuPZ vs=; b=rBYR5PI4LEXAma3Jygqgu/pmBK7wVfHoB1+/EOv1KDUhEdGEqRn2DpDxp X3dVDBmO3rICaTi8hY0SEUtRK7vFni/lYO9co+WvjMSdgTfjVxJ8zPfsV0qaokSR +qA00QpjOScmtWwWK5DJSI5/vbFALEENnlx+R0DlYXjN/cRSJoqAs1+gULVJcG1T w9/vuunfthst4ZT1Cexcvcso0e+jEgCHjtOrnEKz/8bCxeWWbrSAIjdVl9ogiOUu 7hWk0fVv4krz5Q+JZ9DicUGzxti/zQnDaqYhJR6397Rvizfn0uqsR6tAKfKKu2LX KmmSuvZPUgc6RhZgoINbTrLLVxFEg== X-ME-Sender: X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 6B283E446A; Thu, 4 Oct 2018 10:25:34 -0400 (EDT) From: Thomas Monjalon To: "Doherty, Declan" Cc: dev@dpdk.org, gaetan.rivet@6wind.com, ophirmu@mellanox.com, qi.z.zhang@intel.com, ferruh.yigit@intel.com, arybchenko@solarflare.com, konstantin.ananyev@intel.com, bruce.richardson@intel.com, jerin.jacob@caviumnetworks.com, hemant.agrawal@nxp.com Date: Thu, 04 Oct 2018 16:25:32 +0200 Message-ID: <2005070.FcdnsIK129@xps> In-Reply-To: <283f0f5d-7ca1-6e8e-cccb-f922e175157a@intel.com> References: <20180907230958.21402-1-thomas@monjalon.net> <20180928164039.2380-4-thomas@monjalon.net> <283f0f5d-7ca1-6e8e-cccb-f922e175157a@intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v2 3/3] eal: allow probing a device again 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: Thu, 04 Oct 2018 14:25:37 -0000 04/10/2018 11:44, Doherty, Declan: > On 28/09/2018 5:40 PM, Thomas Monjalon wrote: > > In the devargs syntax for device representors, it is possible to add > > several devices at once: -w dbdf,representor=[0-3] > > It will become a more frequent case when introducing wildcards > > and ranges in the new devargs syntax. > > > > If a devargs string is provided for probing, and updated with a bigger > > range for a new probing, then we do not want it to fail because > > part of this range was already probed previously. > > There can be new ports to create from an existing rte_device. > > > > That's why the checks for an already probed device > > are moved as PMD responsibility. > > Only the PMD knows the ports attached to one rte_device. > > > > In the case of vdev, a global check is kept in insert_vdev(), > > assuming that a vdev will always have only one port. > > In the case of NXP buses, the probing is done only once (no hotplug), > > though a check is added at bus level for consistency. > > > > As another consequence of being able to probe in several steps, > > the field rte_device.devargs must not be considered as a full > > representation of the rte_device, but only the latest probing args. > > Anyway, the field rte_device.devargs is used only for probing. > > > > Signed-off-by: Thomas Monjalon > > --- > > Hey Thomas, did you consider of adding a driver flags to the rte_driver > structure which has a driver re-probe flag. If this flag is disabled by > default, current drivers could be left unmodified and any new driver > which want to support re-probing enable this flag and then support the > functionality in there probe function. Then we could check this flag in > the bus driver on making a call on whether to re-probe. I really don't know what is best: - have a standard expectation for all drivers - add a driver flag in order to remove a check If your option is preferred, where the flag should be added? - in rte_driver which has no flag at all so far - in rte_pci_driver.drv_flags which may be enough (at least for now) Opinions?