[ovs-dev] OVS-DPDK public meeting

Christian Ehrhardt christian.ehrhardt at canonical.com
Tue Jun 5 19:38:35 UTC 2018


On Tue, Jun 5, 2018 at 7:04 PM, Aaron Conole <aconole at redhat.com> wrote:

> Hi Christian,
>
> Christian Ehrhardt <christian.ehrhardt at canonical.com> writes:
>
> > On Tue, Jun 5, 2018 at 3:28 PM, Stokes, Ian <ian.stokes at intel.com>
> wrote:
> >> > On Wed, May 30, 2018 at 7:49 PM, Kevin Traynor <ktraynor at redhat.com>
> >> > wrote:
> >> >
> >> > > Minutes of meeting Wed 30th May.
> >> > >
> >> > > [...]
> >> > >
> >> >
> >> >
> >> > > - DPDK 18.05
> >> > > -- Will be released today/tomorrow
> >> > > -- Some delays due to a lot of patches and last minute bug fixes
> >> > >
> >> >
> >> > Hi,
> >> > I wanted to ask if anyone is already looking at DPDK 18.05 toleration
> or
> >> > even exploitation.
> >> >
> >> > I just tried to built recent OVS against it and (there might be more)
> at
> >> > least dpdk change
> >> >   cd8c7c7c ethdev: replace bus specific struct with generic dev
> >> >
> >> > breaks OVS due to code in lib/netdev-dpdk.c accessing that with an
> error
> >> > like:
> >> >
> >> > ../lib/netdev-dpdk.c:2800:17: error: ‘struct rte_eth_dev_info’ has no
> >> > member named ‘pci_dev’
> >> >      if (dev_info.pci_dev) {
> >> >
> >> > I re-built an old 2.9.0, but saw that even on master the code still is
> >> as-
> >> > is, so I assume OVS master and coming 2.9.3 are affected as well.
> >> >
> >>
> >> Thanks for raising Christian,
> >>
> >> It wouldn't be a clean transition from 17.11 to 18.05 as there are a few
> >> changes (as you have spotted). AFAIK there are also changes to the meter
> >> library to provision profiles, this would have to be addressed in OVS
> also.
> >>
> >> > Usually a few days after DPDK there were patches for OVS, but so far I
> >> > found nothing on the mailing list.
> >> > So I wanted to ask if there is someone already (planning to) work on
> >> > these?
> >>
> >> I was planning to if the community agreed it was warranted.
> >>
> >> However the general feeling expressed at the past few community calls is
> >> that the next move should be to DPDK 18.11 LTS and I tend to agree with
> >> this.
> >>
> >> The main advantage of this is the DPDK LTS lifecycle provides bug fixes
> >> for DPDK for 2 years from release. Moving to a non DPDK LTS becomes a
> pain
> >> as critical bug fixes will not be backported on the DPDK side so are not
> >> addressed in OVS with DPDK either, we've seen this with some of the CVE
> >> fixes for vhost quite recently.
> >>
> >> 18.05 is also the largest DPDK release to date with a lot of code being
> >> introduced in the later RC stages which IMO increases the risk rather
> than
> >> the gain of moving to it.
> >>
> >> However I'm open to discussing if a move to 18.05 is warranted, are
> there
> >> any critical features or usecases it enables that you had in mind?
> >>
> > There are always the two big groups of users.
> > - Those that want max stability for a huge Production setup (which would
> > follow the pick LTS argument)
> > - And those that want/need the very latest HW support and features (which
> > would always prefer the latest version)
> > I had no single critical feature in mind for 18.05, but especially your
> > argument of "the largest DPDK release to date with a lot of code being
> > introduced" makes it interesting for the second group.
> > Actually I think there are also plenty of new devices which are not
> > supported at all before 18.02/18.05.
> > So far my DPDK upgrade policy was "the last DPDK available which has at
> > least one point release AND works with OVS".
> > If OpenVswitch really changed to only support to each DPDK LTS version,
> > then I might have to follow that.
> > I must admit I already had the same thought to only pick .11 stable
> > versions, so I'm not totally opposed if that is the way it is preferred
> for
> > Openvswitch.
> > But if we can make this a toleration (saying it works with 17.11 AND
> newer
> > 18.05) then this would be a great contrib to OVS and IMHO be warranted.
> > If the latter would work it could be great to spot issues early on
> instead
> > of having a super-big jump from 17.11 to 18.11 in one shot.
> > But if you have to kill support fot 17.11 to let it work with 18.05, then
> > better not.
> > Interested what other opinions on this are.
>
> /me looks left and right, then dons flame retardant pants
>

Hi Aaron, no need for these :-)


> One of the bigger community hurdles is to impress upon DPDK developers
> the importance of ABI/API stability.  Without this, then applications
> which consume DPDK (Open vSwitch, MoonGen, trex, etc) will always be
> version locked.  Even if the linker/loader doesn't immediately barf,
> there's no guarantee that things aren't broken.
>

I'd like to argue with you, but then can't.
We all know that velocity<->stability is a tradeoff, and being mostly
driven by bleeding edge HW DPDK chose a different focus than most others.
We are back at my statement of the two kinds of people now :-)


OTOH, by sticking with an LTS, we can 'guarantee' (well, with as much
> certainty as anything in life) that we are able to upgrade that version
> of the library without blowing up the world.


If you can get a better ABI/API adherence in DPDK, then I'm all for it
>

I don't have a better model for DPDK to satisfy both groups and will miss
next DPDK conference so I can't even bring it up there (again).
I'm not the one who has the big enough hammer for this problem to be a nail
:-)

I think eventually this will become a question of release-economy.
If all/most consuming projects (not only OVS and similar, but also all
those self-brew custom DPDK solutions) will start to only adapt to each LTS
version, then I think a shift might happen to release less DPDK versions in
general.


> (I'd love if we could just drop version numbers altogether, as it would
> be the most 'natural' for developers and users).
>

If the above happens you can drop YY from the XX.YY naming scheme, is that
enough :-)

I'm glad I brought the topic up, I didn't realize there was so much
sentiment already to need flame retardant pants here :-)
It is probably good to talk about this to be aware of all the opinions on
this.

What I hear so far seems that most (those that replied) started to consider
DPDK .02, .05, .08 versions the .90 version (in OVS terms).
And to consider .11 as the real release to adapt to once a year.

This might be fine until two major projects start to do this differently, I
really would not want to need two DPDK versions at once in Distribution
releases.

Waiting for more people to chime in here what they think ...


> >> Thanks
> >> Ian
> >>
> >> > _______________________________________________
> >> > dev mailing list
> >> > dev at openvswitch.org
> >> > https://mail.openvswitch.org/mailman/listinfo/ovs-dev
> >>
>



-- 
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd


More information about the dev mailing list