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

Stephen Hemminger stephen at networkplumber.org
Thu Aug 1 19:06:38 CEST 2013


On Thu, 01 Aug 2013 17:37:35 +0200
Marc Sune <marc.sune at bisdn.de> wrote:

> Dear all,
> 
> Sorry in advance if there is another API for this and I haven't found 
> it, or if there is a strong reason for having it this way. I've seen 
> that in the case of both baremetal and Linux applications, the way to 
> initialize EAL is passing argv:
> 
> <code>
> //...
>      /* init EAL */
>      ret = rte_eal_init(argc, argv);
>      if (ret < 0)
>          rte_exit(EXIT_FAILURE, "Invalid EAL arguments\n");
>      argc -= ret;
>      argv += ret;
> //...
> </code>
> 
> However, this is a little bit annoying in the case of GNU/Linux 
> user-space applications, hence using DPDK as a library, when porting 
> them to DPDK (specially in case of multi-platform applications, like in 
> our case), since they are not necessarily designed to be changing the 
> main routines in a per platform basis. In our case they are even in 
> separate autotools package, since the library providing DPDK based 
> services needs to be distributed also in binary version, linking to 
> non-DPDK aware code.
> 
> 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>
> 
> 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>
> 
> 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?


We found it more convenient to handle application arguments first before
calling rte_eal_init().  Mostly because application needs to start as daemon,
and eal_init spawns threads.

main(argc, argv) {
	progname = strrchr (argv[0], '/');
	progname = strdup(progname ? progname + 1 : argv[0]);

	ret = parse_args(argc, argv);
	if (ret < 0)
		return -1;
	argc -= ret;
	argv += ret;
...
	if (daemon_mode) {
		if (daemon(1,1) < 0)
			rte_panic("daemon failed\n");
	}

	/* workaround fact that EAL expects progname as first argument */
	argv[0] = progname;
	ret = rte_eal_init(argc, argv);
	if (ret < 0)
		return -1;




More information about the dev mailing list