From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Roger B. Melton" Subject: Re: Making rte_eal_pci_probe() in rte_eal_init() optional? Date: Wed, 18 Nov 2015 17:13:51 -0500 Message-ID: <564CF81F.10103@cisco.com> References: <564B3215.9020103@cisco.com> <1972675.qABnqcockr@xps13> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: dev@dpdk.org, Don Provan To: Thomas Monjalon Return-path: Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by dpdk.org (Postfix) with ESMTP id 822125A92 for ; Wed, 18 Nov 2015 23:14:10 +0100 (CET) In-Reply-To: <1972675.qABnqcockr@xps13> List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Hi Thomas, in-line -Roger On 11/17/15 10:46 AM, Thomas Monjalon wrote: > 2015-11-17 08:56, Roger B. Melton: >> Hi David, in-line -Roger >> >> On 11/16/15 4:46 AM, David Marchand wrote: >>> Hello Roger, >>> >>> On Sun, Nov 15, 2015 at 3:45 PM, Roger B. Melton >> > wrote: >>> >>> I like the "-b all" and "-w none" idea, but I think it might be >>> complicated to implement it the way we would need it to work. The >>> existing -b and -w options persist for the duration of the >>> application, and we would need the "-b all"/"-w none" to persists >>> only through rte_eal_init() time. Otherwise our attempt to to >>> attach a device at a later time would be blocked by the option. >>> >>> I agree, the black/white lists should only apply to initial scan. >>> I forgot about this problem ... >>> I had started some cleanup in the pci scan / attach code but this is >>> too late for 2.2, I will post this in the next merge window. >>> >>> >>> Wouldn't it be simpler to have an option to disable the >>> rte_eal_init() time the probe. Would that address the issue with >>> VFIO, prevent automatically attaching to devices while permitting >>> on demand attach? >>> >>> >>> I suppose we can do this yes (I think Thomas once proposed off-list an >>> option like --no-pci-scan). >>> Do you think you can send a patch ? >> What about --no-pci-init-probe? I know it's long, but it is more >> descriptive of it's purpose to disable only the init time pci probe. > Why not a "-b all"? > Making it work would also solve the case where you to scan only part of > the devices and initialize the blacklisted ones later. > . > Do you envision "-b all" setting a flag that would be used to block rte_eal_init() invocation of rte_eal_pci_probe()? e.g. If we have a new API, *rte_eal_pci_blacklist_all_get()* that returns a non-zero value if "-b all" was specified, then in rte_eal_init() we would have something like: ... /* Probe & Initialize PCI devices */ * if (!rte_eal_pci_blacklist_all_get())** <--- New check* if (rte_eal_pci_probe()) rte_panic("Cannot probe PCI\n"); ... Or setting a flag that would be checked in rte_eal_probe_one() similar to the existing per device blacklist check? e.g. Again with a new API, *rte_eal_pci_blacklist_all_get()* that returns a non-zero value if "-b all" was specified, then in rte_eal_pci_probe_one_driver() we would have something like: /* no initialization when blacklisted, return without error */ if (*rte_eal_pci_blacklist_all_get() || <--- New check* (dev->devargs != NULL && dev->devargs->type == RTE_DEVTYPE_BLACKLISTED_PCI)) { RTE_LOG(DEBUG, EAL, " Device is blacklisted, not initializing\n"); return 1; } The former would work, but I think it would be confusing for "-b all" to only apply to init. The latter would be consistent with how "-b " works, but in order to initialize devices at a later time, we would need a way to clear the blacklist all state at run time so that *rte_eal_pci_blacklist_all()* would return false. For example, something like *rte_eal_pci_blacklist_all_clear()*. Or do you have something else in mind entirely?