"Gray, Mark D" <mark.d.g...@intel.com> writes: >> -----Original Message----- >> From: dev [mailto:dev-boun...@openvswitch.org] On Behalf Of Aaron >> Conole >> Sent: Thursday, December 3, 2015 4:24 AM >> To: dev@openvswitch.org >> Cc: Flavio Leitner >> Subject: [ovs-dev] [RFC 2/2] dpdk: Update INSTALL.DPDK.md to reflect new >> config >> >> A previous change modified the way DPDK configuration would be accepted >> by the system. This updates the documentation to align with the new >> method of configuring DPDK. >> >> Signed-off-by: Aaron Conole <acon...@redhat.com> >> --- >> INSTALL.DPDK.md | 52 ++++++++++++++++++++++++++++++++++++++---- >> ---------- >> 1 file changed, 38 insertions(+), 14 deletions(-) >> >> diff --git a/INSTALL.DPDK.md b/INSTALL.DPDK.md index 96b686c..789ea68 >> 100644 >> --- a/INSTALL.DPDK.md >> +++ b/INSTALL.DPDK.md >> @@ -143,22 +143,46 @@ Using the DPDK with ovs-vswitchd: >> > [Gray, Mark D] > On a general note, I guess for most of these database entries it > doesn’t make sense to > change them at runtime as they only affect the initialization > stage. Off the top of my > head, I can't think of any other entries that behave like this > (perhaps there are > though). Does this mean it would be possible to change them at runtime > which would make the switch look like it was configured in a different way? > Take the number of memory channels as an example. It may not be a problem > but it is strange behavior.
I wrote this approach for two reasons after reading the following: http://openvswitch.org/pipermail/dev/2015-December/062859.html 1. "OTOH the command line variant is perhaps less effort." - I wanted to see how much effort would really be required to do this. It wasn't much to put a strawman together, so here we are. 2. Ben's reply to another similar component: " >> It would seem to make sense to configure DPDK the same way as everything >> else in OVS: through the database. Sounds like what we want. " Why delay the inevitable? :) There are CONs to this approach, no doubt. As you've said there are possibilities for things to go out of sync; that's a good feature to add to this series - ensure that values haven't changed. Possibly we could have a graceful restart facility if someone does change. Not sure how it will look. Anyway, it's the kind of discussion that I want for this change, so I'm hoping others also chime in with thoughts. >> 5. Start vswitchd: >> >> - DPDK configuration arguments can be passed to vswitchd via `--dpdk` >> - argument. This needs to be first argument passed to vswitchd process. >> - dpdk arg -c is ignored by ovs-dpdk, but it is a required parameter >> - for dpdk initialization. >> - >> + DPDK configuration arguments can be passed to vswitchd via the >> Open_vSwitch >> + other_config database. The recognized configuration options are listed. >> + >> + * dpdk >> + This is a boolean configuration option. A value of 'true' tells >> + Open_vSwitch to initialize the DPDK EAL. A set of nominal defaults are >> + provided so that simply enabling this option will be sufficient to >> configure >> + DPDK enabled ports. >> + * dpdk_core_mask >> + This is DPDK's -c command line option, and specifies the core mask to >> + the EAL. > > Why exactly do we need this again? We have "other_config:pmd-cpu-mask" which > should set the affinity of the pmd threads. The affinities of the > other standard pthreads > should by a system administrator. Or, if the intention is that this > would allow us > to set affinities for the other threads, then the name should be > changed to something > more meaningful. I think we don't need a new config and pmd-cpu-mask is the correct value to use for this configuration. I'll make the change when I spin a formal patch. Thanks for the review, Mark! _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
