[dpdk-dev] Non-argv dependant rte_eal_init() call

[Marc Sune]

Dear Thomas,

Regarding the MAIN, then I understand is not really necessary for Linux 
user-space applications, and that is there in the examples because they 
can run both baremetal and userspace... this is fine.

Regarding the rte_eal_init(), if the concern is the number of parameters 
and backwards compatibility, a typical solution is to create a struct 
containing the parameters:

<code>
typedef struct eal_init_params{
     uint64_t coremask;
     unsigned int num_of_cache_lines;
     /* Add here more parmeters in future versions... */
}eal_init_params_t;

int rte_eal_init(eal_init_params_t* params);
</code>

Therefore the user code, is always backwards compatible (provided that 
is properly recompiled).

In any case, and besides the struct approach, I think is more elegant to 
add a parameter to a function call if you jump to a newer version of the 
DPDK, than having to create a fake C string array or forcing the 
applications to add extra DPDK parameters in the executable.

Just my 2 cents ;)

Best
marc

On 01/08/13 18:01, Thomas Monjalon wrote:
> Hello,
>
> 01/08/2013 17:37, Marc Sune :
>> In our case, we are right now simply faking the argv, which is a little
>> bit ugly:
>> <code>
>> //...
>>    37         const char* argv[EAL_ARGS] = {"./fake", "-c",CORE_MASK,
>> "-n",NUM_CACHE_LINES, ""};
>> //...
>>    53         ret = rte_eal_init(EAL_ARGS, (char**)argv);
>>    54         if (ret < 0)
>>    55                 rte_exit(EXIT_FAILURE, "rte_eal_init failed");
>> //...
>> </code>
> You should provide a better binary name because in your example, your logs
> will be prefixed with "fake" which is, I agree with you, a little bit ugly ;)
>
>> IMHO it would make more sense to have actually two calls, adding a
>> library-like initialization. Something like:
>>
>> <code>
>> /*
>> * In the comments a warning that this should be called at the very
>> beginning of the program.
>> *...
>> */
>> int rte_eal_init(eal_coremask_t core_mask, unsigned int num_of_lines
>> /*More parameters here...*/);
>>
>> /*
>> *
>> */
>> int rte_eal_init_argv(int argc, char **argv);
>>
>> </code>
> The problem with your proposal is that the number of options is static.
> So when adding a new option in future releases, all the applications should be
> updated to give a (probably null) value for this new option.
> Not sure it is an improvement.
>
>> Btw, the same applies to the mangling of the main() (MAIN) routine. Is
>> this really necessary? Isn't it enough to clearly state in the
>> documentation that certain API calls need to be made on the very
>> beginning of the application?
> Not sure to understand this point.
> MAIN is only defined in examples for the bare-metal use case.
> What is the link with the API ?
>