All of lore.kernel.org
 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 rte_bus_probe() does not exit on error 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.