Hello Aaron,
On Thursday 12 October 2017 06:50 PM, Aaron Conole wrote:
Shreyansh Jain <shreyansh.j...@nxp.com> writes:
Hello Aaron,
On Tuesday 10 October 2017 09:30 PM, Aaron Conole wrote:
Shreyansh Jain <shreyansh.j...@nxp.com> writes:
Hello Don,
[snip]
[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:
PCI
|- 0000:00:00.0
|- 0000:00:02.0
DPAA2
|- dpni.1
|- dpni.2
<others>
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.
