From: Shreyansh Jain <shreyansh.jain@nxp.com>
To: Aaron Conole <aconole@redhat.com>
Cc: Don Provan <dprovan@bivio.net>,
Jan Blunck <jblunck@infradead.org>,
Thomas Monjalon <thomas@monjalon.net>, dev <dev@dpdk.org>,
Hemant Agrawal <hemant.agrawal@nxp.com>
Subject: Re: [dpdk-dev] [PATCH] eal: bus scan and probe never fail
Date: Thu, 12 Oct 2017 19:53:09 +0530 [thread overview]
Message-ID: <e7357d79-77c3-26f9-1779-6394b59a9c62@nxp.com> (raw)
In-Reply-To: <f7tlgkgcxkq.fsf@dhcp-25-97.bos.redhat.com>
Hello Aaron,
On Thursday 12 October 2017 06:50 PM, Aaron Conole wrote:
> Shreyansh Jain <shreyansh.jain@nxp.com> writes:
>
>> Hello Aaron,
>>
>> On Tuesday 10 October 2017 09:30 PM, Aaron Conole wrote:
>>> Shreyansh Jain <shreyansh.jain@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.
next prev parent reply other threads:[~2017-10-12 14:11 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-12 10:22 Shreyansh Jain
2017-09-18 11:36 ` Hemant Agrawal
2017-09-19 18:51 ` Jan Blunck
2017-10-05 23:21 ` Thomas Monjalon
2017-10-06 13:12 ` Shreyansh Jain
2017-10-06 13:37 ` Thomas Monjalon
2017-10-06 17:34 ` Jan Blunck
2017-10-09 11:10 ` Shreyansh Jain
2017-10-09 18:21 ` Don Provan
2017-10-09 19:34 ` Thomas Monjalon
2017-10-10 5:00 ` Shreyansh Jain
2017-10-10 16:00 ` Aaron Conole
2017-10-11 22:34 ` Thomas Monjalon
2017-10-12 13:08 ` Aaron Conole
2017-10-12 5:39 ` Shreyansh Jain
2017-10-12 13:20 ` Aaron Conole
2017-10-12 14:23 ` Shreyansh Jain [this message]
2017-10-11 0:03 ` Don Provan
2017-10-11 22:32 ` Thomas Monjalon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e7357d79-77c3-26f9-1779-6394b59a9c62@nxp.com \
--to=shreyansh.jain@nxp.com \
--cc=aconole@redhat.com \
--cc=dev@dpdk.org \
--cc=dprovan@bivio.net \
--cc=hemant.agrawal@nxp.com \
--cc=jblunck@infradead.org \
--cc=thomas@monjalon.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).