From mboxrd@z Thu Jan 1 00:00:00 1970 From: Panu Matilainen Subject: Re: rte_eal_init() alternative? Date: Fri, 9 Oct 2015 13:40:18 +0300 Message-ID: <56179992.3080501@redhat.com> References: <44e664970fef4bff942eaee5c7eaca67@bilemail1.empirix.com> <20150902125650.GA10364@bricha3-MOBL3> <3003120.8bdQ5bCz5C@xps13> <56177A00.9060201@redhat.com> <69ead0cc07ec49f884b92de0756de3df@bilemail1.empirix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Cc: "dev@dpdk.org" To: "Montorsi, Francesco" , Thomas Monjalon 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) In-Reply-To: <69ead0cc07ec49f884b92de0756de3df@bilemail1.empirix.com> List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On 10/09/2015 01:03 PM, Montorsi, Francesco wrote: > Hi Panu, > > > >> -----Original Message----- >> From: Panu Matilainen [mailto:pmatilai@redhat.com] >> Sent: venerd=C3=AC 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 thi= s >> 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=20 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=20 configuration which is expected to keep expanding and/or otherwise=20 changing. I'd much rather see an rte_eal_init() which takes struct *rte_cfgfile as=20 the configuration argument. That, plus maybe enhance librte_cfgfile to=20 allow constructing one entirely in memory + setting values in addition=20 to getting. - Panu - > Thanks, > Francesco > > >