From mboxrd@z Thu Jan 1 00:00:00 1970 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) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8525; q=dns/txt; s=iport; t=1447884850; x=1449094450; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=NVzn0OMEqJ2RnwYYmIpiozwwVAkC6eYoqL+IUzD5zz4=; b=c77pjDK6QrkaLBkLChN8n2w9M519cnEQYyhKXzJOX6Sxp9TcCjvpOpFG BclYH7mCpvY6dQqGszYXWAA21hz/LCf8H19gcaft29ZZrrYpYVbpxawfu XeHt/V+hqJvHaGdT1TV6qtj/KesBA7CWVqHwLhTYVN75Tm7CiT/VjVuMW g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AKAgAb90xW/5ldJa1egzuBQr5oAQ2BZ?= =?us-ascii?q?YYPAoFKOBQBAQEBAQEBgQqENQEBBCdSEAsYCR4HDwI1EQYNBgIBAYgqv3YBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEYhlSEfoURhCgFjhKIOAGIEYUZiR2GD40ZHwEBQ?= =?us-ascii?q?oQiIDSFIAEBAQ?= X-IronPort-AV: E=Sophos;i="5.20,315,1444694400"; d="scan'208,217";a="51616717" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Nov 2015 22:14:09 +0000 Received: from [10.82.231.218] (rtp-vpn1-2007.cisco.com [10.82.231.218]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id tAIME8re017607; Wed, 18 Nov 2015 22:14:08 GMT To: Thomas Monjalon References: <564B3215.9020103@cisco.com> <1972675.qABnqcockr@xps13> From: "Roger B. Melton" Message-ID: <564CF81F.10103@cisco.com> Date: Wed, 18 Nov 2015 17:13:51 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <1972675.qABnqcockr@xps13> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Cc: dev@dpdk.org, Don Provan Subject: Re: [dpdk-dev] Making rte_eal_pci_probe() in rte_eal_init() optional? X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Nov 2015 22:14:11 -0000 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?