From: Marc Sune <marc.sune@bisdn.de>
To: Antti Kantee <pooka@iki.fi>
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] Non-argv dependant rte_eal_init() call
Date: Thu, 01 Aug 2013 20:14:29 +0200 [thread overview]
Message-ID: <51FAA585.3080709@bisdn.de> (raw)
In-Reply-To: <51FA9127.8020702@iki.fi>
[-- Attachment #1: Type: text/plain, Size: 3506 bytes --]
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.
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..
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.
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.
Concerning 2), this has a trivial solution, which is define a static
initializer and a (likely inlined) struct initalizer; e.g. pthreads.h does:
|int pthread_mutex_init(pthread_mutex_t */mutex/,
const pthread_mutexattr_t */attr/);
pthread_mutex_t/mutex/ = PTHREAD_MUTEX_INITIALIZER;|
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 ;)
Best
marc
On 01/08/13 18:47, Antti Kantee wrote:
> On 1.8.2013 19:13, Marc Sune wrote:
>> 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).
>
> I don't think that's a good interface because:
> 1) like you say, you need to recompile everything always to make sure
> the passed struct is of the right size
> 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".
> 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.
>
> 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.
>
> My only annoyance is that eal_init() takes a non-const.
>
> - antti
[-- Attachment #2: Type: text/html, Size: 4752 bytes --]
next prev parent reply other threads:[~2013-08-01 18:12 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-01 15:37 Marc Sune
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 [this message]
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=51FAA585.3080709@bisdn.de \
--to=marc.sune@bisdn.de \
--cc=dev@dpdk.org \
--cc=pooka@iki.fi \
/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).