Hi Andy, Andy Zhou <az...@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 <acon...@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 ;) _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
