From: Marc Sune <marc.sune@bisdn.de>
To: dev@dpdk.org
Subject: [dpdk-dev] Non-argv dependant rte_eal_init() call
Date: Thu, 01 Aug 2013 17:37:35 +0200 [thread overview]
Message-ID: <51FA80BF.2020801@bisdn.de> (raw)
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?
Best
Marc
---
BISDN GmbH
Marc Suñé Clos
Christburger Straße 45, 10405 Berlin, Germany
Berlin Institute for Software Defined Networks - BISDN GmbH
Managing Directors: Dr.-Ing. Hagen Woesner, Andreas Köpsel
Commercial register: Amtsgericht Berlin-Charlottenburg HRB 141569 B
VAT ID No: DE283257294
Corporate seat: Berlin
next reply other threads:[~2013-08-01 15:35 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-01 15:37 Marc Sune [this message]
2013-08-01 16:01 ` Thomas Monjalon
2013-08-01 16:13 ` Marc Sune
2013-08-01 16:47 ` Antti Kantee
2013-08-01 18:14 ` Marc Sune
2013-08-01 17:06 ` Stephen Hemminger
2013-08-01 18:17 ` Marc Sune
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=51FA80BF.2020801@bisdn.de \
--to=marc.sune@bisdn.de \
--cc=dev@dpdk.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).