<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Well, I would not want to get into
religious discussions here :), but concerning 1) and 3) you have
to compile anyway your final applications, since as far as I've
seen current DPDK makefiles are only compiling static versions of
the lib. <br>
<br>
Moreover, I don't think it is feasible to assume that the future
versions of DPDK are going to maintain the exact same headers
(APIs and data structures), basically due to the new HW supported
and additional features that DPDK is going to (hopefully) support.
So at the very end this requires a recompilation anyway. But very
likely you know more about this detail than I do, so I could be
wrong here..<br>
<br>
Along this, I personally think that in end-user applications these
parameters (CPU_CORES, channels...) will be either compile time
constants or config file parameters, rather than arguments to the
program. At least in our case, we plan to optimize it for several
platforms and so on, but as a final application there is no need
(and it can be harmful) to expose this to the enduser. Besides,
most of the programs have already their own parameters that are
meaningful for the application.<br>
<br>
Unless you are profiling, or simply checking SDK examples (in here
yes, it is great, this is why I think it must be kept), I think
that having such DPDK HW specific argvs is not that useful.<br>
<br>
Concerning 2), this has a trivial solution, which is define a
static initializer and a (likely inlined) struct initalizer; e.g.
pthreads.h does:<br>
<br>
<pre><code>int pthread_mutex_init(pthread_mutex_t *<i>mutex</i>,
const pthread_mutexattr_t *<i>attr</i>);
pthread_mutex_t <i>mutex</i> = PTHREAD_MUTEX_INITIALIZER;</code></pre>
<br>
In any case, for the moment I will continue faking argv's. If I
get more upset about this piece of code, I will try to implement
this call and send the patch here for discussion. At the very end,
it was only a suggestion ;)<br>
<br>
Best<br>
marc<br>
<br>
On 01/08/13 18:47, Antti Kantee wrote:<br>
</div>
<blockquote cite="mid:51FA9127.8020702@iki.fi" type="cite">On
1.8.2013 19:13, Marc Sune wrote:
<br>
<blockquote type="cite">Regarding the rte_eal_init(), if the
concern is the number of parameters
<br>
and backwards compatibility, a typical solution is to create a
struct
<br>
containing the parameters:
<br>
<br>
<code>
<br>
typedef struct eal_init_params{
<br>
uint64_t coremask;
<br>
unsigned int num_of_cache_lines;
<br>
/* Add here more parmeters in future versions... */
<br>
}eal_init_params_t;
<br>
<br>
int rte_eal_init(eal_init_params_t* params);
<br>
</code>
<br>
<br>
Therefore the user code, is always backwards compatible
(provided that
<br>
is properly recompiled).
<br>
</blockquote>
<br>
I don't think that's a good interface because:
<br>
1) like you say, you need to recompile everything always to make
sure the passed struct is of the right size
<br>
2) it's less obvious how to pass optional parameters, or more
accurately, how to not pass them. You could add some
eal_init_defaults() interface, but see "3".
<br>
3) with every DPDK upgrade you need to evaluate new members of the
struct to determine their default values. Mandatory parameters
need to be addressed either way, but at least the current scheme
gives an explicit error if you omit one instead of defaulting to
some perhaps unwanted behavior.
<br>
<br>
I think the current way of passing of a string tuple vector is
fine, though I agree it's a little counter-intuitive when you need
to invent argv[0] in case you're not just passing in argv[]
opaquely. I pass "if_dpdk" from my TCP driver, and I haven't lost
too much sleep over it.
<br>
<br>
My only annoyance is that eal_init() takes a non-const.
<br>
<br>
- antti
<br>
</blockquote>
<br>
</body>
</html>