[dpdk-dev] [PATCH] eal: bus scan and probe never fail

Shreyansh Jain shreyansh.jain at nxp.com
Thu Oct 12 16:23:09 CEST 2017

Hello Aaron,

On Thursday 12 October 2017 06:50 PM, Aaron Conole wrote:
> Shreyansh Jain <shreyansh.jain at nxp.com> writes:
>> Hello Aaron,
>> On Tuesday 10 October 2017 09:30 PM, Aaron Conole wrote:
>>> Shreyansh Jain <shreyansh.jain at nxp.com> writes:
>>>> Hello Don,
>> [snip]


>> I am assuming that that aim of this is to have a way so that
>> application can query whether its device of interest is there or
>> not. But, I think this (creating a list of scan errrors) would be
>> overkill.
> No.  That can be done through a different query.

OK. So, aim is to know errors, if any, that might have occurred when 
DPDK scan (just after rte_eal_init) would have occurred.
(Assuming probe is just based on successful scan, lets just ignore that 
for a while.)

>> Even if we were to create a list of errors from scan/probe, how would
>> that help an application? Is there some specific use-case that you are
>> hinting at?
> Sure.  Let's assume that due to some permissions problem, /proc/bus/pci
> doesn't exist for the application.  The entire PCI bus scan fails.  No
> PCI devices are found.

Agree - that is a general scan failure.
It will end up detecting any non-PCI devices which are present. So, lets 
say for this available device tree:

  |- 0000:00:00.0
  |- 0000:00:02.0
  |- dpni.1
  |- dpni.2

DPDK scan would detect only DPAA2 devices. PCI devices are absent and no 
port id (post probe) would be assigned to any of them.

> In this case, how can the application even start to understand why the
> device is missing?  I don't think parsing logs makes sense.  But if
> there's a way to see that the PCI bus scan/probe failed, maybe the
> application can start making corrective action (for instance, check that
> /proc is mounted, and retry the bus probe/scan).

See below.

>> Application should worry about devices rather than how they are being
>> detected (scan/probe etc). Application can use API like
>> rte_eth_dev_get_port_by_name to query its specific device of
>> interest. If the scan has failed, this API would be sufficient for the
>> application to take counter-measures. Isn't that enough from a DPDK
>> application perspective to move from init to I/O?
> I'm not sure what you're asking here.  I agree that bus probe/scan
> shouldn't ever fail, and that we should pass from init to i/o asap.

What I had in mind that applications are more concerned about devices 
that it requires than environment issues because of which scan failed.
An application would try and query:

   ret = rte_eth_dev_get_port_by_name("0000:00:00.0")

resulting in an error.
Obviously, at this point it is too late to make changes like you 
suggested ("/proc"...retry bus/scan) - (hotplugging?).
My assumption was that at this point application would take necessary 
action (error, quit) when its devices are not available.

Application should not be worried about 'scan/probe' process - that is 
an internal operation, outcome of which (ports) is what application want.
Again, this is just my opinion.

>> I am not discounting that there might be some higher use-cases where
>> this list might come of us - but I can't think of one right now and I
>> can't comment on this proposal in absence of that understanding -
>> sorry.
> Maybe the above helps?  Not sure if I described my thinking.

I understand your point.
Maybe a wider audience would be better judge of usability of this model. 
I think you should go ahead and propose this a proper patch/RFC.

More information about the dev mailing list