[ovs-dev] [PATCH v3 00/16] port Jiri Benc's L3 patchset to ovs

[Yang, Yi Y]

Jan, I'm ok, I will rebase those patches once ovs maintainers merge your patches first. In my patches, I added vxlan-gpe user space support, that needs those three user space patches, that is why I included those three user space patches in my patch set.

I don't know what order ovs maintainers will merge them in. I can only focus on userspace support for vxlan-gpe if ovs maintainers really merge your patches first.

-----Original Message-----
From: Jan Scheurich [mailto:jan.scheurich at ericsson.com] 
Sent: Thursday, February 9, 2017 5:50 PM
To: Yang, Yi Y <yi.y.yang at intel.com>; Joe Stringer <joe at ovn.org>; Jiri Benc (jbenc at redhat.com) <jbenc at redhat.com>; Eric Garver <e at erig.me>
Cc: dev at openvswitch.org; Jarno Rajahalme (jarno at ovn.org) <jarno at ovn.org>
Subject: RE: [ovs-dev] [PATCH v3 00/16] port Jiri Benc's L3 patchset to ovs

Hi Yi,

I very much doubt that it makes sense to first merge the obsolete user-space patches and then override them with the target version. 

Jarno and Joe have in principle agreed to merge the new user-space patches independently of the backport of the kernel datapath patches. So there is no dependency in this direction.

If it is not possible to merge the kernel datapath back-ports without test cases, then I think the datapath merge should wait for the merge of the new user-space patches and then add end-to-end test cases for the kernel datapath as well.

But perhaps such end-to-end tests are not strictly necessary. It appears to me that Jiri's L3 tunneling datapath patches were merged into net-next without such test cases (just based on code review). So why not in OVS tree?

We can then add end-to-end kernel datapath tests when the Eric's outstanding user-space patches for rtnetlink and compat tunnel configuration for L3 tunnels are added.

BR, Jan


> -----Original Message-----
> From: Yang, Yi Y [mailto:yi.y.yang at intel.com]
> Sent: Wednesday, 08 February, 2017 06:31
> To: Jan Scheurich <jan.scheurich at ericsson.com>; Joe Stringer 
> <joe at ovn.org>; Jiri Benc (jbenc at redhat.com) <jbenc at redhat.com>; Eric 
> Garver <e at erig.me>
> Cc: dev at openvswitch.org
> Subject: RE: [ovs-dev] [PATCH v3 00/16] port Jiri Benc's L3 patchset 
> to ovs
> 
> I'll check how we can rebase your changes against those three patches 
> on top of my patches, our goals are same, that is to merge your 
> changes and this patch set to ovs. I don't know what order Joe will merge them in. Obviously one patch set can't depend on another one which isn't nailed down to merge or not.
> 
> Jan, let us have a sync by lync meeting.
> 
> -----Original Message-----
> From: Jan Scheurich [mailto:jan.scheurich at ericsson.com]
> Sent: Wednesday, February 8, 2017 7:19 AM
> To: Joe Stringer <joe at ovn.org>; Yang, Yi Y <yi.y.yang at intel.com>; Jiri 
> Benc (jbenc at redhat.com) <jbenc at redhat.com>; Eric Garver <e at erig.me>
> Cc: dev at openvswitch.org
> Subject: RE: [ovs-dev] [PATCH v3 00/16] port Jiri Benc's L3 patchset 
> to ovs
> 
> Hi Yi,
> 
> Both Joe and Jarno have indicated there are no principle problems 
> merging our self-contained user-space patches for L3 tunneling. May I 
> suggest that you (together with Jiri and Eric) focus on the datapath back-ports and the user-space patches on top needed to configure L3 tunnels in the net-next and OVS tree kernel module.
> 
> /Jan
> 
> > -----Original Message-----
> > From: Joe Stringer [mailto:joe at ovn.org]
> > Sent: Tuesday, 07 February, 2017 18:55
> > To: Yang, Yi Y <yi.y.yang at intel.com>
> > Cc: Jan Scheurich <jan.scheurich at ericsson.com>; dev at openvswitch.org
> > Subject: Re: [ovs-dev] [PATCH v3 00/16] port Jiri Benc's L3 patchset 
> > to ovs
> >
> > On 7 February 2017 at 05:28, Yang, Yi Y <yi.y.yang at intel.com> wrote:
> > > Jan, I know that, but per Joe's comments, it seems he won't merge your patch set unless the part in kernel side is merged before them.
> > It can't work without these three patches.
> >
> > I have primarily expressed concern about missing kernel patch 
> > backports due to inconsistent backporting order. If Jan's series is 
> > decoupled and still builds OK, tests OK, passes review, etc by 
> > itself then I'm not sure I understand the dependency on the kernel patches.