From: Shreyansh Jain <shreyansh.jain@nxp.com>
To: Jan Blunck <jblunck@infradead.org>,
Thomas Monjalon <thomas@monjalon.net>
Cc: dev <dev@dpdk.org>, Hemant Agrawal <hemant.agrawal@nxp.com>
Subject: Re: [dpdk-dev] [PATCH] eal: bus scan and probe never fail
Date: Mon, 9 Oct 2017 16:40:03 +0530 [thread overview]
Message-ID: <83422f57-4c0e-5806-c741-ed5ce10891b0@nxp.com> (raw)
In-Reply-To: <CALe+Z03Ez1f4=fRSbn7eZXQryXBYA8d1e8zCtbmWUTZw0bPSgg@mail.gmail.com>
On Friday 06 October 2017 11:04 PM, Jan Blunck wrote:
> On Fri, Oct 6, 2017 at 3:37 PM, Thomas Monjalon <thomas@monjalon.net> wrote:
>> 06/10/2017 15:12, Shreyansh Jain:
>>> On Friday 06 October 2017 04:51 AM, Thomas Monjalon wrote:
>>>> 19/09/2017 20:51, Jan Blunck:
>>>>> On Mon, Sep 18, 2017 at 1:36 PM, Hemant Agrawal <hemant.agrawal@nxp.com> wrote:
>>>>>> Tested-by: Hemant Agrawal <hemant.agrawal@nxp.com>
>>>>>>
>>>>>>
>>>>>> On 8/12/2017 3:52 PM, Shreyansh Jain wrote:
>>>>>>>
>>>>>>> Bus scan is responsible for finding devices over *all* buses.
>>>>>>> Some of these buses might not be able to scan but that should
>>>>>>> not prevent other buses to be scanned.
>>>>>>>
>>>>>
>>>>> If scanning the bus fails this is signaling an error. In that case we
>>>>> might even want to unregister the bus.
>>>>
>>>> A scan error seems important enough to be reported to the caller.
>>>> OK to continue scanning other buses, but an error code should be returned.
>>>
>>> Isn't that counter intuitive if the scanning continues after error and
>>> an error is expected to be returned from it?
>>> What if there are more than one error? Which one is reported.
>>
>> Both are reported with the same code.
>> Anyway, there is no way to know which bus is failing,
>> except from log.
>>
>
> Correct. Also there is no way to handle that failure except for
> reporting it to the log in all detail.
Even now both, scan and probe, are reporting error to EAL if scan or
probe fail. This is what you are suggesting, isn't it?
>
>
>>> As for cleanup, bus un-registration is not correct. Scan has failed,
>>> which might mean some assumption that bus took for scanning for devices
>>> doesn't exist for time being or present platform. Either way, I think
>>> whatever rollback needs to be done for scan failure, would be done by
>>> the bus->scan() implementation.
>>>
>>> Let me know what you think - I will make changes to the patch and push
>>> again.
>>
>> We may need more opinion here.
>>
>> Mine is that we should not hide a scan failure.
>
> Hide scan failures? Do you mean hiding it from the log? I wouldn't do that.
I think Thomas was of the opinion to *not* hide scan failure.
Reporting through logs works fine here, I guess.
>
>> I would return an error code if any of the scan has failed,
>> but would process every scans.
>
> FWIW I agree.
>
This is where I have disagreement/doubt.
Reporting error code from rte_bus_scan would do two things:
1. rte_eal_init is not designed to ignore/log-only these errors - it
would quit initialization. (But, this can be changed)
2. What should rte_eal_init do with this error? rte_bus_scan would have
already printed the problematic bus->scan() failure.
Also, does it make sense to report error from rte_bus_scan() to
rte_eal_init() when no buses are identified? Currently that is not
happening.
-
Shreyansh
next prev parent reply other threads:[~2017-10-09 10:57 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 [this message]
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
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=83422f57-4c0e-5806-c741-ed5ce10891b0@nxp.com \
--to=shreyansh.jain@nxp.com \
--cc=dev@dpdk.org \
--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).