From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gemini.bisdn.de (gemini.bisdn.de [212.91.241.169]) by dpdk.org (Postfix) with ESMTP id 747674C6E for ; Thu, 1 Aug 2013 18:11:35 +0200 (CEST) Received: from [192.168.207.121] (unknown [185.27.182.16]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by gemini.bisdn.de (Postfix) with ESMTPSA id 6EA6D82349; Thu, 1 Aug 2013 18:08:59 +0200 (CEST) Message-ID: <51FA891D.2070702@bisdn.de> Date: Thu, 01 Aug 2013 18:13:17 +0200 From: Marc Sune User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130704 Icedove/17.0.7 MIME-Version: 1.0 To: Thomas Monjalon References: <51FA80BF.2020801@bisdn.de> <201308011801.08070.thomas.monjalon@6wind.com> In-Reply-To: <201308011801.08070.thomas.monjalon@6wind.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: dev@dpdk.org Subject: Re: [dpdk-dev] Non-argv dependant rte_eal_init() call X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 16:11:35 -0000 Dear Thomas, Regarding the MAIN, then I understand is not really necessary for Linux user-space applications, and that is there in the examples because they can run both baremetal and userspace... this is fine. 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: 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); Therefore the user code, is always backwards compatible (provided that is properly recompiled). In any case, and besides the struct approach, I think is more elegant to add a parameter to a function call if you jump to a newer version of the DPDK, than having to create a fake C string array or forcing the applications to add extra DPDK parameters in the executable. Just my 2 cents ;) Best marc On 01/08/13 18:01, Thomas Monjalon wrote: > Hello, > > 01/08/2013 17:37, Marc Sune : >> In our case, we are right now simply faking the argv, which is a little >> bit ugly: >> >> //... >> 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"); >> //... >> > You should provide a better binary name because in your example, your logs > will be prefixed with "fake" which is, I agree with you, a little bit ugly ;) > >> IMHO it would make more sense to have actually two calls, adding a >> library-like initialization. Something like: >> >> >> /* >> * 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); >> >> > The problem with your proposal is that the number of options is static. > So when adding a new option in future releases, all the applications should be > updated to give a (probably null) value for this new option. > Not sure it is an improvement. > >> 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? > Not sure to understand this point. > MAIN is only defined in examples for the bare-metal use case. > What is the link with the API ? >