Re: [RFC] kernel paramters like DPDK CLI options

[Yerden Zhumabekov <e_zhumabekov@sts.kz>]

I recently felt tired enough of specifying various options for EAL, so I 
came up to use ini-based configuration. EAL parameters from dedicated 
section of ini file are parsed to argv array which is subsequently fed 
to rte_eal_init(). Quite handy, but maybe a little overkill.


On 01.06.2016 12:04, Yuanhan Liu wrote:
> Hi all,
>
> I guess we (maybe just me :) have stated few times something like
> "hey, this kind of stuff is good to have, but you are trying to
> add an EAL CLI option for a specific subsystem/driver, which is
> wrong".
>
> One recent example that is still fresh in my mind is the one from
> Christian [0], that he made a proposal to introduce two new EAL
> options, --vhost-owner and --vhost-perm, to configure the vhost
> user socket file permission.
>
>      [0]: http://dpdk.org/ml/archives/dev/2016-April/037948.html
>
> Another example is the one I met while enabling virtio 1.0 support.
> QEMU has the ability to support both virtio 0.95 (legacy) and 1.0
> (modern) at the same time for one virtio device, therefore, we
> could either use legacy driver or modern driver to operate the
> device. However, the current logic is we try with modern driver
> first, and then legacy driver if it failed. In above case, we will
> never hit the legacy driver. But sometimes, it's nice to let it
> force back to the legacy driver, say, for debug or compare purpose.
>
> Apparently, adding a new EAL option like "--force-legacy" looks
> wrong.
>
> The generic yet elegant solution I just thought of while having
> lunch is to add a new EAL option, say, --extra-options, where we
> could specify driver/subsystem specific options. As you see, it's
> nothing big deal, it just looks like Linux kernel parameters.
>
> Take above two cases as example, it could be:
>
>      --extra-options "vhost-owner=kvm:kvm force-legacy"
>
> Note that those options could also be delimited by comma.
>
> DPDK EAL then will provide some generic helper functions to get
> and parse those options, and let the specific driver/subsystem
> to invoke them to do the actual parse and do the proper action
> when some option is specified, say, virtio PMD driver will force
> back to legacy driver when "force-legacy" is given.
>
> Comments? Makes sense to you guys, or something nice to have?
>
> 	--yliu