Making rte_eal_pci_probe() in rte_eal_init() optional?
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
Hello Roger,
Quoted 12 lines · Roger B Melton
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 therte_eal_pci_probe()invocation. This caused problems later on when when our control process, instructed our DPDK process to attach to a device.
Quoted 7 lines
There are a number of ways we could address this, but the simplest is to prevent the
rte_eal_pci_probe()atrte_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.
Signature · 1 line
David Marchand
Hi David,
Quoted 26 lines · David Marchand
Hello Roger,
On Thu, Nov 12, 2015 at 11:43 PM, Roger B Melton <[email protected] <mailto:[email protected]>> 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 therte_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()atrte_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?
Quoted 5 lines
Did you try the --no-pci option ?
It avoids the initial sysfs scan, so with no pci device, the initialpci_probeshould 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
Quoted 4 lines
Signature · 2 lines
-- David Marchand
Signature · 16 lines
____________________________________________________________________ |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 .:|||||||:..:|||||||:. [email protected] | | | | 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 ____________________|