DPDK patches and discussions
 help / color / mirror / Atom feed
From: "McDaniel, Timothy" <timothy.mcdaniel@intel.com>
To: "dev@dpdk.org" <dev@dpdk.org>
Subject: rte_bus_probe() does not exit on error
Date: Mon, 18 Apr 2022 13:20:10 +0000	[thread overview]
Message-ID: <SN6PR11MB3103A5A4CE6D4C5846FDAB999EF39@SN6PR11MB3103.namprd11.prod.outlook.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 1819 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 6927 bytes --]

             reply	other threads:[~2022-04-18 13:20 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-18 13:20 McDaniel, Timothy [this message]
2022-05-02 21:20 McDaniel, Timothy
2022-05-02 21:54 ` Thomas Monjalon
2022-05-03  9:52   ` Tyler Retzlaff
2022-05-03 10:14     ` Thomas Monjalon
2022-05-11 20:49       ` 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=SN6PR11MB3103A5A4CE6D4C5846FDAB999EF39@SN6PR11MB3103.namprd11.prod.outlook.com \
    --to=timothy.mcdaniel@intel.com \
    --cc=dev@dpdk.org \
    /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).