From mboxrd@z Thu Jan 1 00:00:00 1970 From: Roger B Melton Subject: Making rte_eal_pci_probe() in rte_eal_init() optional? Date: Thu, 12 Nov 2015 17:43:38 -0500 Message-ID: <5645161A.3010107@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit To: dev@dpdk.org Return-path: Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by dpdk.org (Postfix) with ESMTP id 3591D9221 for ; Thu, 12 Nov 2015 23:43:59 +0100 (CET) Received: from [10.82.254.63] (rtp-vpn6-1593.cisco.com [10.82.254.63]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id tACMhvsb015669 for ; Thu, 12 Nov 2015 22:43:57 GMT 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 folks, With the addition of hot plug support we have been migrating away from device discovery and attach at initialization time to a model where it is controlled from a separate process. The separate process manages the binding of devices to UIO and instructs the DPDK process when to attach. One of the problems we stumbled onto was that if our control process discovered devices and bound them to UIO before our DPDK process started, then rte_eal_init() would discover and attach to those devices via the rte_eal_pci_probe() invocation. This caused problems later on when when our control process, instructed our DPDK process to attach to a device. There are a number of ways we could address this, but the simplest is to prevent the rte_eal_pci_probe() at rte_eal_init() time. In our model we will never need it and I suspect others may also be in that boat. What are your thoughts on adding an argument to instruct rte_eal_init() to skip the PCI probe? Thanks, -Roger