[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