On 05/02/2016 04:15, "Traynor, Kevin" <kevin.tray...@intel.com> wrote:
> >> -----Original Message----- >> From: dev [mailto:dev-boun...@openvswitch.org] On Behalf Of Daniele Di >> Proietto >> Sent: Friday, February 5, 2016 2:22 AM >> To: Flavio Leitner; Aaron Conole; Andy Zhou >> Cc: <dev@openvswitch.org> >> Subject: Re: [ovs-dev] [PATCH v8 0/5] Convert DPDK configuration from >>command >> line to DB based >> >> 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 main benefit I see of these patches is that it removes a requirement >for >the user to have knowledge of DPDK init params by providing defaults, >while >also catering for a power user who wants to set them. That's also a good point. > > >> >> 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. > >That's noted for -n. >+ /* XXX: DPDK 2.2.0 support, the true should become false for -n >*/ > > >Using the DPDK default -c (all cores) is not ideal as it will create a >thread on every core which will not be used. Anyway, whatever about >creating something for passing the DPDK init, the real default that is >now provided is that the control type threads in vswitchd will run with >the same affinity as vswitchd. That allows for use of the existing >threading >model in vswitchd and that by default those threads will float across >multiple cores as scheduled by Linux. You're right, I guess it still makes sense for OVS to explicitly pass to DPDK a fake '-c' Thanks for your input > >A power >> user is still able to influence them via the extra options > >That's true, they could alternatively be set through extra options. > >With the exception of socket-mem, I don't think 99% of users will want to >set -c or -n anymore once defaults are provided. > >Kevin. > >> >> 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 _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
