DPDK patches and discussions
 help / color / mirror / Atom feed
From: Thomas Monjalon <thomas@monjalon.net>
To: Tyler Retzlaff <roretzla@linux.microsoft.com>
Cc: "McDaniel, Timothy" <timothy.mcdaniel@intel.com>,
	"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: Tue, 03 May 2022 12:14:25 +0200	[thread overview]
Message-ID: <4331513.Mh6RI2rZIc@thomas> (raw)
In-Reply-To: <20220503095239.GB5181@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net>

03/05/2022 11:52, Tyler Retzlaff:
> On Mon, May 02, 2022 at 11:54:29PM +0200, Thomas Monjalon wrote:
> > 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.
> 
> a bit of a tangent but it would be nice if eal initialization wasn't
> coupled to bus/device enumeration at all and instead there was more
> control over bus/device enumeration where the application could choose if
> it wants the error to be fatal or not .. after eal was initialized.

I agree with the idea.

> with it burried inside eal initialization the application has no control
> over the policy to fail or not, also there are other peripherial
> problems that arise due to the composition e.g. event callbacks can't
> be registered until after probe from init has occurred and eal init
> is completed.
> 
> it would be a huge compat break (i'm ignoring that) but so would
> failing eal init for reasons it does not currently fail.

Yes compatibility is a blocker.

A better idea would be to not use rte_eal_init() at all.
I am convinced we should split this function in multiple parts.
It would allow keeping compatibility with the legacy function
while allowing more flexibility with new functions.

You may be interested by this talk:
https://fast.dpdk.org/events/slides/DPDK-2018-09-Default.pdf



  reply	other threads:[~2022-05-03 10:14 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
2022-05-03  9:52   ` Tyler Retzlaff
2022-05-03 10:14     ` Thomas Monjalon [this message]
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=4331513.Mh6RI2rZIc@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=roretzla@linux.microsoft.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).