From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Monjalon Subject: Re: [PATCH v2 3/3] eal: allow probing a device again Date: Thu, 04 Oct 2018 16:25:32 +0200 Message-ID: <2005070.FcdnsIK129@xps> 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-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit 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 To: "Doherty, Declan" 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) In-Reply-To: <283f0f5d-7ca1-6e8e-cccb-f922e175157a@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" 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?