[dpdk-dev] [PATCH] eal: bus scan and probe never fail
shreyansh.jain at nxp.com
Thu Oct 12 16:23:09 CEST 2017
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,
>> 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
> 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:
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).
>> 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 -
> 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