From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id 4356D902 for ; Fri, 9 Oct 2015 18:03:13 +0200 (CEST) Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (Postfix) with ESMTPS id 4CA6AC0BE098 for ; Fri, 9 Oct 2015 16:03:12 +0000 (UTC) Received: from [10.10.59.182] (vpn-59-182.rdu2.redhat.com [10.10.59.182]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t99G32Ur002206 for ; Fri, 9 Oct 2015 12:03:06 -0400 To: dev@dpdk.org References: <44e664970fef4bff942eaee5c7eaca67@bilemail1.empirix.com> <20150902125650.GA10364@bricha3-MOBL3> <3003120.8bdQ5bCz5C@xps13> <56177A00.9060201@redhat.com> <69ead0cc07ec49f884b92de0756de3df@bilemail1.empirix.com> <56179992.3080501@redhat.com> From: Thomas F Herbert Organization: Red Hat Message-ID: <5617E534.4060808@redhat.com> Date: Fri, 9 Oct 2015 17:03:00 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <56179992.3080501@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 Subject: Re: [dpdk-dev] rte_eal_init() alternative? 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: Fri, 09 Oct 2015 16:03:13 -0000 On 10/9/15 11:40 AM, Panu Matilainen wrote: > On 10/09/2015 01:03 PM, Montorsi, Francesco wrote: >> Hi Panu, >> >> >> >>> -----Original Message----- >>> From: Panu Matilainen [mailto:pmatilai@redhat.com] >>> Sent: venerdì 9 ottobre 2015 10:26 >>> To: Montorsi, Francesco ; Thomas Monjalon >>> >>> Cc: dev@dpdk.org >>> Subject: Re: [dpdk-dev] rte_eal_init() alternative? >>> >>>> Something like the attached patch. >>> >>> It seems the patch missed the boat :) >> >> Correct, sorry. I'm attaching it now. >> >> >>> >>>> Note that the attached patch exposes also a way to skip the argv/argc >>>> configuration process by directly providing a populated configuration >>>> structure... >>>> Let me know what you think about it (the patch is just a draft and >>>> needs more work). >>> >>> Can't comment on what I've not seen, but based on comments seen on this >>> list, having an alternative way to initialize with structures would >>> be welcomed >>> by many. The downside is that those structures will need to be >>> exposed in >>> the API forever which means any changes there are subject to the ABI >>> process. >>> >> Perhaps the init function taking a structure could be an exception >> for ABI changes... i.e., the format of the configuration is not >> garantueed to stay the same between different versions, and >> applications using a shared build of DPDK libraries must avoid using >> the configuration structure... would that be a possible solution? > > Sorry but no, down the path of exceptions lies madness. It'd also be > giving the middle finger to people using DPDK as a shared library. > > Exported structs are always a PITA and even more so in something like > configuration which is expected to keep expanding and/or otherwise > changing. > > I'd much rather see an rte_eal_init() which takes struct *rte_cfgfile > as the configuration argument. That, plus maybe enhance librte_cfgfile > to allow constructing one entirely in memory + setting values in > addition to getting. > > - Panu - It is very difficult for application writers to write their own command parsers with implementation for -h option. How about a function that would verify the init parameters and return with a benign error if the options are not correct. > > > > >> Thanks, >> Francesco >> >> >> > -- Thomas F Herbert Red Hat