DPDK patches and discussions
 help / color / mirror / Atom feed
From: Thomas Monjalon <thomas@monjalon.net>
To: "McDaniel, Timothy" <timothy.mcdaniel@intel.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
	"Van Haaren, Harry" <harry.van.haaren@intel.com>,
	Jerin Jacob <jerinj@marvell.com>,
	"Wires, Kent" <kent.wires@intel.com>,
	david.marchand@redhat.com
Subject: Re: rte_bus_probe() does not exit on error
Date: Mon, 02 May 2022 23:54:29 +0200	[thread overview]
Message-ID: <10320642.NyiUUSuA9g@thomas> (raw)
In-Reply-To: <SN6PR11MB31031062362BEB41DE3D24F59EC19@SN6PR11MB3103.namprd11.prod.outlook.com>

Hello,

02/05/2022 23:20, McDaniel, Timothy:
> Hello DPDK community,
> 
> I am following up on a question/comment that I submitted on April 18, for which
> I have not received any responses. See the original comment below for context.
> 
> Are there objections to modifying the behavior of rte_bus_probe() so that it propagates
> any errors detected while processing the command line arguments? It currently ignores
> errors and continues on, always returning success instead of any error that was returned
> by the probe function.

You are suggesting to stop if probing of one device fails.
I am not sure it is a good idea, because sometimes we are OK
to proceed even if one device is missing.

We could differentiate a fatal error like parsing syntax,
and "normal error" of a device which cannot be probed in some conditions.


> > -----Original Message-----
> > Hello DPDK community,
> > 
> > We are looking into an issue where we pass an invalid command line argument
> > to a vdev, and we print out an error message but don't exit.  This is an issue with
> > all of the command line options that we handle in dlb2_parse_params().  In a
> > nutshell, it looks like when we encounter an error in parsing, the error code is
> > propagated to event_dlb2_vdev_probe() (event_dlb2_pci_probe() for PF), which
> > is called by EAL during device probe in rte_bus_probe().  The problem is that
> > rte_bus_probe() calls the .probe function for each device but doesn't exit on
> > error:
> > 
> > if (vbus) {
> >                 ret = vbus->probe();
> >                 if (ret)
> >                         RTE_LOG(ERR, EAL, "Bus (%s) probe failed.\n", vbus->name);
> > }
> > return 0;
> > 
> > We want to exit if the command line arguments can't be parsed, so we have a
> > couple of options:
> > 
> > 
> >   1.  In the DLB PMD, if we get an error while parsing parameters, exit right
> > away.
> >   2.  Change the behavior of rte_bus_probe() so that it propagates the error,
> > which causes the program to exit due to EAL error.
> > 
> > if (vbus) {
> >                 ret = vbus->probe();
> >                 if (ret) {
> >                         RTE_LOG(ERR, EAL, "Bus (%s) probe failed.\n", vbus->name);
> >                         return ret;
> >                 }
> > }
> > return 0;
> > 
> > Any preference, or other ideas?  Option 1 is simple and contained in our code,
> > but does call rte_exit() from library code.  I'm not sure if that's really an issue
> > because we do want to exit if the DLB-specific options are malformed.  Option 2
> > is simple and seems like a better option, but requires changes outside of DLB, so
> > may be more difficult to upstream?  (There may be reasons why the error is
> > ignored for some devices).  Let me know what you think.
> > 
> > Thanks you for your comments,
> > Tim McDaniel




  reply	other threads:[~2022-05-02 21:54 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-02 21:20 McDaniel, Timothy
2022-05-02 21:54 ` Thomas Monjalon [this message]
2022-05-03  9:52   ` Tyler Retzlaff
2022-05-03 10:14     ` Thomas Monjalon
2022-05-11 20:49       ` McDaniel, Timothy
  -- strict thread matches above, loose matches on Subject: below --
2022-04-18 13:20 McDaniel, Timothy

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=10320642.NyiUUSuA9g@thomas \
    --to=thomas@monjalon.net \
    --cc=david.marchand@redhat.com \
    --cc=dev@dpdk.org \
    --cc=harry.van.haaren@intel.com \
    --cc=jerinj@marvell.com \
    --cc=kent.wires@intel.com \
    --cc=timothy.mcdaniel@intel.com \
    /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).