Re: [dpdk-dev] rte_eal_init() alternative?

[Marc Sune <marc@voltanet.io>]

Stephen, Don,

On Wed, Sep 2, 2015 at 9:00 PM, Stephen Hemminger <
stephen@networkplumber.org> wrote:

> 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.
>

That's one of the first things I was asking in the mailing list (argv):

http://dpdk.org/ml/archives/dev/2013-August/000374.html

I still think the same way.


> >
> > -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.
>
> 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.
>

Yes sure, and that's what all of us who are integrating DPDK in existing
applications is doing:

https://github.com/bisdn/xdpd/blob/stable/src/xdpd/drivers/gnu_linux_dpdk/src/hal-imp/driver.cc#L153-L157

But that's rather a workaround.

Instead, having an eal_init() API which only handles a fixed set of
arguments (non-argv) that can be used by existing applications, and build a
command line API on top of eal_init() that parses argv as of now (e.g.
eal_init_cl) seems to me cleaner. There are users that make use of the
parsing of argv (e.g. dpdk-pktgen) in DPDK, so I think it makes sense to
keep it.

So if you'd agree on this general proposal, I will try to allocate some
time for refactoring this.

Marc


>
> 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"
>
>