From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.cs.hut.fi (mail.cs.hut.fi [130.233.192.7]) by dpdk.org (Postfix) with ESMTP id 74D4F4C6E for ; Thu, 1 Aug 2013 18:47:13 +0200 (CEST) Received: from [IPv6:::1] (hutcs.cs.hut.fi [130.233.192.10]) by mail.cs.hut.fi (Postfix) with ESMTPS id 15670308670 for ; Thu, 1 Aug 2013 19:47:37 +0300 (EEST) Message-ID: <51FA9127.8020702@iki.fi> Date: Thu, 01 Aug 2013 19:47:35 +0300 From: Antti Kantee MIME-Version: 1.0 To: dev@dpdk.org References: <51FA80BF.2020801@bisdn.de> <201308011801.08070.thomas.monjalon@6wind.com> <51FA891D.2070702@bisdn.de> In-Reply-To: <51FA891D.2070702@bisdn.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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:47:13 -0000 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: > > > 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). 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