From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [67.231.154.164]) by dpdk.org (Postfix) with ESMTP id C980B1E25 for ; Mon, 8 Oct 2018 10:06:12 +0200 (CEST) X-Virus-Scanned: Proofpoint Essentials engine Received: from webmail.solarflare.com (uk.solarflare.com [193.34.186.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by mx1-us1.ppe-hosted.com (Proofpoint Essentials ESMTP Server) with ESMTPS id C313DB00060; Mon, 8 Oct 2018 08:06:11 +0000 (UTC) Received: from [192.168.38.17] (91.220.146.112) by ukex01.SolarFlarecom.com (10.17.10.4) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 8 Oct 2018 09:06:06 +0100 To: Thomas Monjalon , CC: , , , References: <20180907230958.21402-1-thomas@monjalon.net> <20181007220933.4533-1-thomas@monjalon.net> <20181007220933.4533-4-thomas@monjalon.net> From: Andrew Rybchenko Message-ID: Date: Mon, 8 Oct 2018 11:05:24 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <20181007220933.4533-4-thomas@monjalon.net> Content-Language: en-GB X-Originating-IP: [91.220.146.112] X-ClientProxiedBy: ocex03.SolarFlarecom.com (10.20.40.36) To ukex01.SolarFlarecom.com (10.17.10.4) X-TM-AS-Product-Ver: SMEX-12.5.0.1300-8.5.1010-24142.003 X-TM-AS-Result: No-14.281000-8.000000-10 X-TMASE-MatchedRID: X4bcv0S75KkOwH4pD14DsPHkpkyUphL9Ct59Uh3p/NVcKZwALwMGsz6l 3VPPG5GaR5KBY5usn0y3DO15nGjZ0wkTDfdheATAGUkpc56lLW2YZJKiXhR6LcJ3vzMzuod4QVl SEo8CA+JfHs4V++as1lepNGRh1yYrX9X5Ym9InIK3UCG/IQp2Pr/MqlpyYVLBuPDHG2o8VrD3mu Lh+GPYb3sDRMTOXRzqXM9RaNLxmh70YoyPps8M9P28T9BUNXkhX5TqQagR07dJ4wL74VrmWPNO7 flRFqXmIGSHKu90xKWSU848M/hs6Me4Woyb+kVFyDp+jSvEtWsl3afZehJEWedlU2K5Jm9bggBA sUW5uWTOH38lNbOoTFxI2ZZX9m4X319rGX8jiaGeAiCmPx4NwLTrdaH1ZWqC1B0Hk1Q1KyLUZxE AlFPo81CtqpPvhRDG3xgyPPbLD3YxhfsQpNfLtUwIU38y50z6COXLzGmeM9qROTGWeJYspY8Phm dSFX9HoODqAGY5hc155MR4DIDHYTMA2xC7+yXo X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-TMASE-Result: 10--14.281000-8.000000 X-TMASE-Version: SMEX-12.5.0.1300-8.5.1010-24142.003 X-MDID: 1538985972-CYbzRYnemYyq Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] [PATCH v3 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: Mon, 08 Oct 2018 08:06:13 -0000 On 10/8/18 1:09 AM, 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 check for an already probed device > is moved as bus responsibility. > 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 ifpga and vmbus, already probed devices are checked. > In the case of NXP buses, the probing is done only once (no hotplug), > though a check is added at bus level for consistency. > In the case of PCI, a driver flag is added to allow PMD probing again. > Only the PMD knows the ports attached to one rte_device. > > 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 Reviewed-by: Andrew Rybchenko