Re: [dpdk-dev] rte_eal_init() alternative?

[Panu Matilainen <pmatilai@redhat.com>]

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 <fmontorsi@empirix.com>; Thomas Monjalon
>> <thomas.monjalon@6wind.com>
>> 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
>
>
>