dev.dpdk.org archive mirror
 help / color / mirror / Atom feed
From: Stephen Hemminger <stephen-OTpzqLSitTUnbdJkjeBofR2eb7JE58TQ@public.gmane.org>
To: Marc Sune <marc.sune-kpkqNMk1I7M@public.gmane.org>
Cc: dev-VfR2kkLFssw@public.gmane.org
Subject: Re: Non-argv dependant rte_eal_init() call
Date: Thu, 1 Aug 2013 10:06:38 -0700	[thread overview]
Message-ID: <20130801100638.4c0f06a8@samsung-9> (raw)
In-Reply-To: <51FA80BF.2020801-kpkqNMk1I7M@public.gmane.org>

On Thu, 01 Aug 2013 17:37:35 +0200
Marc Sune <marc.sune-kpkqNMk1I7M@public.gmane.org> 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;

  parent reply	other threads:[~2013-08-01 17:06 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-01 15:37 Non-argv dependant rte_eal_init() call Marc Sune
     [not found] ` <51FA80BF.2020801-kpkqNMk1I7M@public.gmane.org>
2013-08-01 16:01   ` Thomas Monjalon
     [not found]     ` <201308011801.08070.thomas.monjalon-pdR9zngts4EAvxtiuMwx3w@public.gmane.org>
2013-08-01 16:13       ` Marc Sune
     [not found]         ` <51FA891D.2070702-kpkqNMk1I7M@public.gmane.org>
2013-08-01 16:47           ` Antti Kantee
     [not found]             ` <51FA9127.8020702-X3B1VOXEql0@public.gmane.org>
2013-08-01 18:14               ` Marc Sune
2013-08-01 17:06   ` Stephen Hemminger [this message]
2013-08-01 18:17     ` Marc Sune
     [not found]       ` <51FAA647.7070709-kpkqNMk1I7M@public.gmane.org>
2013-08-01 19:23         ` Stephen Hemminger
2013-08-01 20:22           ` Balazs Nemeth

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130801100638.4c0f06a8@samsung-9 \
    --to=stephen-otpzqlsittunbdjkjebofr2eb7je58tq@public.gmane.org \
    --cc=dev-VfR2kkLFssw@public.gmane.org \
    --cc=marc.sune-kpkqNMk1I7M@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).