[ovs-dev] [PATCH v8 0/5] Convert DPDK configuration from command line to DB based

[Aaron Conole]

Hi Andy,

Andy Zhou <azhou at ovn.org> writes:
> Sorry for jumping in late in the review cycle. But I am not sure if there is significant advantage in
> store dpdk options in OVSDB.

No problem - always good to have a fresh pair of eyes. Additionally, the
cover letter should be updated, because I wrote it in a hurry and it
doesn't state the advantages clearly.

Thanks very much for the review!

If folks believe this is not worthwhile, or feel the other way, it would
be nice to hear from them - get an ACK or NAK, or anything else? :) I'm
okay dropping this, btw, if folks think it isn't worthwhile, and all
that. I'd prefer not to, given how much work has gone into it, though.

> On Fri, Jan 29, 2016 at 9:56 AM, Aaron Conole <aconole at redhat.com> wrote:
>
>
>  Currently, configuration of DPDK parameters is done via the command line
>  through a --dpdk **OPTIONS** -- command line argument. This has a number of
>  challenges, including:
>  * It must be the first option passed to ovs-vswitchd
>
>
> This can be improved by specifying dpdk options in quotes, as --dpdk "options", then --dpdk can be
> any where in the command line.

Sure, and that solves the positional requirement, but requiring that we
have to put quotes around dpdk options (when we _know_ there will be
many - it's not like you can get away with no options), is really
hacky. At least, I think so.

>  * It breaks from the way most other things are configured in OVS
>
>
> ovs-vswitchd still has command line options.

Sure, but they're all 'logistic' - where to reach the database, and how
to configure the logging. None are 'features' (for instance, PMD thread
affinities).

It remains that dpdk is the only major feature in OVS which requires
passing command line arguments. 

>  * It doesn't allow an easy way to populate defaults
>
>
> why not? Is there an example? 

Sure - if I install openvswitch, I must manually add the dpdk arguments
to the ovs-ctl. Then when I add them, as a user, I MUST go through a
trial/error process of finding the dpdk switches to invoke. 

It is possible to put all of the additional parsing logic (like I do) to
not use the database; I was interested in moving to using the database,
since there is a desire from others to eliminate passing dpdk options
outside the database.

> One draw back of storing command line options in OVSDB is that ovs-vswitchd needs to connect to
> OVSDB first to learn about those options.
> In case we still want ovs-vswitch to drop user privilege, it will be good to only connect to OVSDB
> server as a regular user.

Yes, I agree this would be a drawback. I have not looked into what it
takes, but even with the current mechanism, dpdk is explicitly
incompatible with --user; my patch doesn't change that.

> The other draw back is to handle version difference -- ovs-vswitchd and dpdk version can change
> over time, but ovsdb content *should* be compatible
> across versions. Storing too much configuration parameters make ovsdb become more version
> dependent.

I can't comment on that. You're probably right, but I don't know what
the future holds ;)