From: Thomas Monjalon <thomas.monjalon@6wind.com>
To: Don Provan <dprovan@bivio.net>
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] rte_eal_init() alternative?
Date: Wed, 02 Sep 2015 23:08:48 +0200 [thread overview]
Message-ID: <1964148.0REVA6fuqc@xps13> (raw)
In-Reply-To: <20150902120039.69e3809c@urahara>
2015-09-02 12:00, Stephen Hemminger:
> On Wed, 2 Sep 2015 18:17:40 +0000
> Don Provan <dprovan@bivio.net> wrote:
>
> > Thomas Monjalon:
> > >Yes but please, do not create an alternative init function.
> > >We just need to replace panic/exit with error codes and be sure that apps and examples handle them correctly.
> >
> > I understand your concerns, but the panics are really just the tip of the iceberg of the EAL library not realizing it's a library. It really makes no sense to think the library should define the application's command line, or that the PCI bus should be probed without considering whether this application is going to use PCI, and or to insist that EAL work be done on internal EAL threads.
> >
> > So I'd say it's way past time to consider revamping initialization to start the process of ending the DPDK library's tail wagging the application's dog. Naturally this would have to be done while retaining the existing init routine on top of a real library initialization, but that's just an unfortunate artifact of the library's history, not a rational design decision for moving forward.
> >
> > -don provan
> >
>
> You are welcome to submit patches with what you are proposing for review.
> Theoretical requirements discussions will probably only result in more mail,
> not new code. You know what you want, propose a solution.
+1
Everybody agree that DPDK should be more flexible.
We move from a bare metal framework to a real library.
They are shortcuts in original design which can be changed.
> As far as the command line. That is easily managed by realizing the application
> doesn't have to pass the original command line into EAL. If you just view the
> command line as a way to pass unstructured options; the application or infrastructure
> can build up new values and pass it in.
>
> I agree that initialization itself should try and not fail except in the
> most extreme cases. "ie I can't find /sys what is wrong" and should try
> and adapt more "you asked for 128 cpu's but I see only 2, log it and continue"
>
next prev parent reply other threads:[~2015-09-02 21:09 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-02 12:49 Montorsi, Francesco
2015-09-02 12:56 ` Bruce Richardson
2015-09-02 13:10 ` Thomas Monjalon
2015-09-02 18:17 ` Don Provan
2015-09-02 19:00 ` Stephen Hemminger
2015-09-02 20:50 ` Marc Sune
2015-09-02 21:08 ` Thomas Monjalon [this message]
2015-09-02 22:01 ` Wiles, Keith
2015-09-08 18:01 ` Don Provan
2015-09-11 17:15 ` Wiles, Keith
2015-10-08 14:58 ` Montorsi, Francesco
2015-10-09 8:25 ` Panu Matilainen
2015-10-09 10:03 ` Montorsi, Francesco
2015-10-09 10:13 ` Montorsi, Francesco
2015-10-09 11:12 ` Panu Matilainen
2015-10-09 10:40 ` Panu Matilainen
2015-10-09 16:03 ` Thomas F Herbert
2015-09-02 14:08 ` Jay Rolette
2015-09-02 19:23 ` Zoltan Kiss
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=1964148.0REVA6fuqc@xps13 \
--to=thomas.monjalon@6wind.com \
--cc=dev@dpdk.org \
--cc=dprovan@bivio.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).