[ovs-dev] [PATCH v8 0/5] Convert DPDK configuration from command line to DB based

Aaron Conole aconole at redhat.com
Sat Feb 20 22:02:07 UTC 2016


Aaron Conole <aconole at redhat.com> writes:

> Daniele Di Proietto <diproiettod at vmware.com> writes:
>
>> On 09/02/2016 09:48, "Traynor, Kevin" <kevin.traynor at intel.com> wrote:
>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: Aaron Conole [mailto:aconole at redhat.com]
>>>> Sent: Friday, January 29, 2016 5:57 PM
>>>> To: dev at openvswitch.org
>>>> Cc: Flavio Leitner <fbl at sysclose.org>; Panu Matilainen
>>>><pmatilai at redhat.com>;
>>>> Traynor, Kevin <kevin.traynor at intel.com>; Zoltan Kiss
>>>> <zoltan.kiss at linaro.org>; Christian Ehrhardt
>>>> <christian.ehrhardt at canonical.com>
>>>> Subject: [PATCH v8 0/5] Convert DPDK configuration from command line to
>>>>DB
>>>> based
>>>> 
>>>> 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
>>>> * It breaks from the way most other things are configured in OVS
>>>> * It doesn't allow an easy way to populate defaults
>>>> 
>>>> 
>>>> This series brings the following changes to openvswitch:
>>>> * All DPDK options are taken from the ovs database rather than the
>>>>   command line
>>>> * DPDK lcores are optionally auto-assigned to a single core based on the
>>>>   bridge coremask.
>>>> * Updated documentation
>>>> 
>>>> v2:
>>>> * Dropped the vhost-user socket configuration options. Those can be
>>>>re-added
>>>>   as an extension
>>>> * Incorporated feedback from Kevin Traynor.
>>>> 
>>>> v3:
>>>> * Went back to a global dpdk-init
>>>> * Language cleanup and various minor fixes
>>>> 
>>>> v4:
>>>> * Added a way to pass arbitrary eal arguments
>>>> 
>>>> v5:
>>>> * Restore the socket-mem default, and fix up the ovs-dev.py script,
>>>>along
>>>>   with the manpage for ovsdb-server
>>>> 
>>>> v6:
>>>> * Correct a documentation issue with INSTALL.DPDK.md
>>>> * Correct a non-dpdk enabled OVS incorrect warning variable
>>>> * Remove an excess whitespace
>>>> 
>>>> v7:
>>>> * After testing by Christian with dpdk-alloc-mem
>>>> 
>>>> v8:
>>>> * Confirmed ``make check`` operation with and without dpdk.
>>>>   Retested on live-host
>>>
>>>Hi,
>>>
>>>I've done some testing on this patchset and I couldn't find any issues.
>>> - tested that -c and -n defaults and explicit values are catered for
>>> - tested dpdk-init=t/f leads to dpdk initialization or not
>>> - tested that use of both dpdk-socket-mem and dpdk-alloc-mem is caught
>>> - tested that a string can be passed in through extra_args
>>> - tested the code won't catch using a db entry dpdk-socket-mem and also
>>>   putting --socket-mem in extra_args, however dpdk will barf
>>>
>>>On command line args vs. db entries vs. a string of args in the db, if
>>>there
>>>is doubt on this then let's debate further. This will change how ovs with
>>>dpdk is used, so better debate it out and get it right.
>>
>> I don't have any particular preference on command line vs database.  As
>> Jesse
>> pointed out having them in the database might help making them run-time
>> configurable (even though they're not today).
>
> I agree with this very much :). 
>
>>>
>>>There's one or two of the db entries that may be able to reused later for
>>>other things e.g. vhostuser socket location, so that would be a + for
>>>them.
>>>Backwards compatibility would be a + for command line args. Daniele has
>>>mentioned scripting also. I'm sure there's other +/-'s.
>>
>> Again, IMHO, this is quite important.  Having to start OVS just to write a
>> value in the database and the restart it again seems wasteful.  If we want
>> to go with the database, we should figure out how to integrate with
>> ovs-ctl.
>
> Perhaps there could be something like (just brainstorming):
>
> ovs-ctl set-db-value "key=value" which would start the database, set the
> parameter, and stop the database. Then there could be a
> --restart-vswitchd flag?
>
> Just throwing out a wild idea. I honestly don't know what makes the most
> sense from a "user experience" perspective.

Thinking further on this, would it make sense for ovs-ctl to have a
separate start-db and start-forwarding commands? At this point, both of
those actions exist as shell functions, so it's really just a matter of
a bit of cleanup and calling the appropriate start function. At that
point, the user can actually start the db, make all the dpdk changes
required, and then start the switching path. If that makes sense I can
submit a quick patch to enable this kind of workflow.

I think it will also enable a systemd integration in the sense that
systemd wants one service per service file. Current approach starts both
in the nonetwork script (which really doesn't make sense
anyway... nonetwork actually does enable networking), but with ovs-ctl
supporting both a start-db and start-forwarding call, there could be two
services.

Just another thought. Would be good to know what folks think.

>>>
>>>Kevin.
>>>
>>>> 
>>>> Aaron Conole (5):
>>>>   netdev-dpdk: Restore thread affinity after DPDK init
>>>>   netdev-dpdk: Convert initialization from cmdline to db
>>>>   netdev-dpdk: Autofill lcore coremask if absent
>>>>   netdev-dpdk: Allow arbitrary eal arguments
>>>>   NEWS: Announce the DPDK EAL configuration change
>>>> 
>>>>  FAQ.md                     |   6 +-
>>>>  INSTALL.DPDK.md            |  90 ++++++++++---
>>>>  NEWS                       |   5 +
>>>>  lib/netdev-dpdk.c          | 327
>>>>++++++++++++++++++++++++++++++++++++++-----
>>>> --
>>>>  lib/netdev-dpdk.h          |  22 ++-
>>>>  utilities/ovs-dev.py       |   7 +-
>>>>  vswitchd/bridge.c          |   3 +
>>>>  vswitchd/ovs-vswitchd.8.in |   5 +-
>>>>  vswitchd/ovs-vswitchd.c    |  25 +---
>>>>  vswitchd/vswitch.xml       | 128 +++++++++++++++++-
>>>>  10 files changed, 513 insertions(+), 105 deletions(-)
>>>> 
>>>> --
>>>> 2.5.0
>>>
> _______________________________________________
> dev mailing list
> dev at openvswitch.org
> http://openvswitch.org/mailman/listinfo/dev



More information about the dev mailing list