Stephen, Don, On Wed, Sep 2, 2015 at 9:00 PM, Stephen Hemminger < stephen at networkplumber.org> wrote:
> On Wed, 2 Sep 2015 18:17:40 +0000 > Don Provan <dprovan at 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" > >
