On 9/8/15, 1:01 PM, "Don Provan" <dprovan at bivio.net> wrote:
>From: Wiles, Keith: >>That stated I am not a big fan of huge structures being passed into >>a init routine as that structure would need to be versioned and it will >>grow/change. Plus he did not really want to deal in strings, so the >>structure would be binary values and strings as required. > >A typical library has an init routine which establishes defaults, and >then the application adjusts parameters through targeted set routines >before starting to use the library operationally. In the argc/argv >wrapper, the parsing code would call one of those individual routines >when it parses the corresponding command line flag. > >The idea that there has to be one massive init routine which is >passed every possible configuration parameter is more of the same >monolithic thinking that DPDK needs to shake. I am not sure DPDK has a lot of monolithic parts, so I do not fully understand your statement, if you mean we should carefully add this support in the correct way then I agree. Some items may need to be passed into the first routine and other items can be set via the setter routines. The problem is the current routine does it all at once and it will need go be broken down to do as you say with setter routines. Passing in a few options or a small structure can still work, but we should not try to create a huge structure. Today we have one API rte_eal_init() and breaking this up into 20 routines is going to be a problem IMO, we need to strike a balance of some type that does not use argc/argv or we add new APIs. > >-don provan >dprovan at bivio.net > ? Regards, ++Keith Intel Corporation
