[ovs-dev] [RFC 2/2] dpdk: Update INSTALL.DPDK.md to reflect new config

[Aaron Conole]

"Gray, Mark D" <mark.d.gray at intel.com> writes:
>> -----Original Message-----
>> From: dev [mailto:dev-bounces at openvswitch.org] On Behalf Of Aaron
>> Conole
>> Sent: Thursday, December 3, 2015 4:24 AM
>> To: dev at 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 <aconole at 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!