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

Traynor, Kevin kevin.traynor at intel.com
Wed Feb 10 17:40:20 UTC 2016


> -----Original Message-----
> From: Aaron Conole [mailto:aconole at bytheb.org]
> Sent: Wednesday, February 10, 2016 1:23 PM
> To: Traynor, Kevin <kevin.traynor at intel.com>
> Cc: dev at openvswitch.org; Flavio Leitner <fbl at sysclose.org>; Mooney, Sean K
> <sean.k.mooney at intel.com>
> Subject: Re: [ovs-dev] [PATCH v8 0/5] Convert DPDK configuration from command
> line to DB based
> 
> "Traynor, Kevin" <kevin.traynor at intel.com> writes:
> >> -----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.
> 
> Cool; does that mean I have your Tested-by? :)

Yes, you can add Tested-by and Acked-by for me. I'm Signed-off-by on 1/5
so my ack doesn't make sense for that one.

> 
> >  - 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 think there's any real doubt. I think the approach is the best
> way to do this. I have agreement from almost everyone else, I think?
> Anyone still need to be convinced?
> 
> > 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.
> 
> I don't know - scripting vswitchd? I think that sounds a little strange;
> it isn't some kind of ephemeral service that comes and goes. And it's
> not like this patch prevents the same kinds of arbitrary commands to be
> passed to the EAL (since 4/5 does precisely that). The only change
> required is doing ovs-vsctl before ovs-vswitch in the 'starting
> vswitchd' case. Is that really a huge deal?
> 
> There's always pros and cons. I haven't heard any explict NAK, or any
> explicit ACK. It would be nice for that to happen, since I can't
> maintain this series out-of-tree forever, and there are other things I'd
> really like to get to (as fun as db entries may be).
> 
> Any suggestions on how to move forward? I was planning on posting a
> rebased v9 - should I still do that?
> 
> -Aaron
> 
> > 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