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 A867F5949 for ; Fri, 9 Oct 2015 12:40:21 +0200 (CEST) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id A4A0E19F228; Fri, 9 Oct 2015 10:40:20 +0000 (UTC) Received: from dhcp195.koti.laiskiainen.org (vpn1-6-191.ams2.redhat.com [10.36.6.191]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t99AeJWP011003; Fri, 9 Oct 2015 06:40:19 -0400 To: "Montorsi, Francesco" , Thomas Monjalon References: <44e664970fef4bff942eaee5c7eaca67@bilemail1.empirix.com> <20150902125650.GA10364@bricha3-MOBL3> <3003120.8bdQ5bCz5C@xps13> <56177A00.9060201@redhat.com> <69ead0cc07ec49f884b92de0756de3df@bilemail1.empirix.com> From: Panu Matilainen Message-ID: <56179992.3080501@redhat.com> Date: Fri, 9 Oct 2015 13:40:18 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <69ead0cc07ec49f884b92de0756de3df@bilemail1.empirix.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 Cc: "dev@dpdk.org" 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 10:40:22 -0000 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 - > Thanks, > Francesco > > >