On 06/05/2018 04:40 PM, Christian Ehrhardt wrote:
> 
> 
> On Tue, Jun 5, 2018 at 3:28 PM, Stokes, Ian <ian.sto...@intel.com
> <mailto:ian.sto...@intel.com>> wrote:
> 
>     > On Wed, May 30, 2018 at 7:49 PM, Kevin Traynor <ktray...@redhat.com 
> <mailto:ktray...@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.
> 

+1. Also, consider that it's not just a few bug fixes - it's hundreds.

The OVS branches are typically bug fix only, so what seems ok now,
doesn't look as nice in 3 months time when there are no more DPDK bug
fixes and something is not working. Take that recent DPDK CVE as an
example (but it would be the same for any DPDK bug)

OVS 2.6 uses DPDK 16.07     - no CVE fix
OVS 2.7 uses DPDK 16.11 LTS - CVE fix
OVS 2.8 uses DPDK 17.05     - no CVE fix
OVS 2.9 uses DPDK 17.11 LTS - CVE fix

>     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.
>

I think it's best to be sticky to LTS and only consider moving if
there's a new compelling ready to go feature, or there's support for a
new device that people need - and has been tested :-)

Kevin.

> 
>     Thanks
>     Ian
> 
>     > _______________________________________________
>     > dev mailing list
>     > d...@openvswitch.org <mailto:d...@openvswitch.org>
>     > https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>     <https://mail.openvswitch.org/mailman/listinfo/ovs-dev>
> 
> 
> 
> 
> -- 
> Christian Ehrhardt
> Software Engineer, Ubuntu Server
> Canonical Ltd

_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Reply via email to