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: Fri, 13 Nov 2015 07:07:00 -0500 Message-ID: <5645D264.7040201@cisco.com> References: <5645161A.3010107@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: "dev@dpdk.org" To: David Marchand Return-path: Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by dpdk.org (Postfix) with ESMTP id BBC6C9404 for ; Fri, 13 Nov 2015 13:07:04 +0100 (CET) In-Reply-To: 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 David, On 11/13/15 3:49 AM, David Marchand wrote: > Hello Roger, > > On Thu, Nov 12, 2015 at 11:43 PM, Roger B Melton > wrote: > > 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? > > > Did you try the --no-pci option ? > It avoids the initial sysfs scan, so with no pci device, the initial > pci_probe should do nothing. > > Attaching devices later will trigger this sysfs scan and only probe > the requested device. > I am not totally happy with the way it is done right now, but I think > this should work for you. I saw it, but I was so caught up in the probe that I didn't consider that delaying the scan until attach time might solve the problem. I'll give it shot. Thanks for pointing it out David. Regards, -Roger > > > -- > David Marchand -- ____________________________________________________________________ |Roger B. Melton | | Cisco Systems | |CPP Software :|: :|: 7100 Kit Creek Rd | |+1.919.476.2332 phone :|||: :|||: RTP, NC 27709-4987 | |+1.919.392.1094 fax .:|||||||:..:|||||||:. rmelton@cisco.com | | | | This email may contain confidential and privileged material for the| | sole use of the intended recipient. Any review, use, distribution | | or disclosure by others is strictly prohibited. If you are not the | | intended recipient (or authorized to receive for the recipient), | | please contact the sender by reply email and delete all copies of | | this message. | | | | For corporate legal information go to: | | http://www.cisco.com/web/about/doing_business/legal/cri/index.html | |__________________________ http://www.cisco.com ____________________|