Sorry for jumping in so late on this.
I'm absolutely not a fan of the way we currently handle DPDK command
line options, so thanks Aaron for taking this initiative.
I think that one of the main reasons for this series, correct me if I'm
wrong, is that it's currently hard to start OVS with DPDK from the
init scripts.
The init script 'ovs-ctl' starts both the database and vswitchd.
The DPDK parameters should be written by the user in the database
with ovs-vsctl, after the database is started, but before vswitchd is.
Currently there's no chance to do so.
The user can still influence the behavior of ovs-ctl by editing
/etc/default/openvswitch-switch and then ovs-ctl could either
populate the database or use command line arguments for
ovs-vswitchd.
I'm not an expert on init scripts though, any input is appreciated.
One more thing: DPDK 2.2 made -c and -n optional with commits
4fce65a6be17("eal: default to using all cores") and
19bfa4ddb1a9("eal: make the -n argument optional"), so I'm not sure
we should provide a default and expose them to the user. A power
user is still able to influence them via the extra options
Daniele
On 04/02/2016 07:38, "Flavio Leitner" <f...@sysclose.org> wrote:
>On Thu, 04 Feb 2016 09:51:05 -0500
>Aaron Conole <acon...@redhat.com> wrote:
>
>> 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.
>
>That becomes an exception not only to OVS but to other services.
>I found very unusual to have to use:
>
>--dpdk "-c ff00 --socket-mem=1024,0" --nochdir ....
>
>and then you have to provide some way to the user to customize that.
>
>
>> > * 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.
>
>DPDK options are actually the datapath configuration (how much mem,
>which socket, where to run PMDs...) . As we do with other configs,
>we should store them in the DB as well, just happen that the kernel DP
>doesn't have any.
>
>[...]
>> > 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 ;)
>
>Same issue with command line arguments right? Both are exposed to
>users, so we would have to keep them around anyway to not break any
>scripts.
>
>--
>fbl
>
>_______________________________________________
>dev mailing list
>dev@openvswitch.org
>http://openvswitch.org/mailman/listinfo/dev
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
