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

[Jarno Rajahalme]

> On Mar 2, 2017, at 11:56 AM, Joe Stringer <j...@ovn.org> wrote:
> 
> Thanks for looking it over, that sounds reasonable. I'll be looking
> forward along the other backports to try to get us back in better sync
> with upstream.
> 
> I will mention that at this stage, the tree that I pointed to is
> missing the MPLS GSO backport but everything else should be up to date
> until the end of the L3 tunnelling series. I'll follow up on the MPLS
> GSO thread regarding that[0].
> 
> [0] http://patchwork.ozlabs.org/patch/725891/
> 

I agree that we should not block everything else on this MPLS backport issue, 
so IMO you could merge the tree with the understanding the we’ll deal with the 
MPLS soon after.

  Jarno

> On 1 March 2017 at 20:23, Yang, Yi Y <yi.y.y...@intel.com> wrote:
>> Joe, I checked this tree 
>> https://github.com/joestringer/openvswitch/commits/dev/backport_review_v0.6 
>> , it included all the 802.1ad patches and Jiri's l3 kernel data path 
>> patches, so I think this is the first step we should take, once they are 
>> officially merged, Jan and I will rework userspace l3 patches and vxlangpe 
>> patches and resubmit them based on your tree.
>> 
>> -Original Message-
>> From: Joe Stringer [mailto:j...@ovn.org]
>> Sent: Thursday, March 2, 2017 11:43 AM
>> To: Yang, Yi Y <yi.y.y...@intel.com>
>> Cc: ovs dev <d...@openvswitch.org>; Jarno Rajahalme <ja...@ovn.org>
>> Subject: Re: [ovs-dev] [PATCH v3 00/16] port Jiri Benc's L3 patchset to ovs
>> 
>> On 6 February 2017 at 05:04, Yi Yang <yi.y.y...@intel.com> wrote:
>>> This patch set just ports Jiri Benc's L3 8 support patches for layer 3 
>>> encapsulated packets from net-next to current ovs, it also includes Jiri 
>>> Benc's 3 userspace patches, Jarno Rajahalme and Pravin Shelar's vlan fix 
>>> patches for L3 patchset as well as my 3 patches which enabled vxlangpe in 
>>> compat mode and dpdk netdev in both L2 and L3(layer3=true) mode.
>>> 
>>> This patchset has been verified on Ubuntu 14.04 x86_64 with Linux kernel 
>>> 3.13.0-24-generic and 4.9.7, it also passed "make check"
>>> and "sudo make check-kmod RECHECK=yes" in Fedora 23 with kernel
>>> 4.2.3-300.fc23.x86_64
>>> 
>>> This patch set is based on 
>>> https://mail.openvswitch.org/pipermail/ovs-dev/2017-February/328492.html 
>>> ([PATCH v2 0/4] Backport 802.1ad patches), please merge this one after 
>>> merging [PATCH v2 0/4] Backport 802.1ad patches.
>>> 
>>> Yi Yang (16):
>>>  datapath: use hard_header_len instead of hardcoded ETH_HLEN
>>>  datapath: add mac_proto field to the flow key
>>>  datapath: pass mac_proto to ovs_vport_send
>>>  datapath: support MPLS push and pop for L3 packets
>>>  datapath: add processing of L3 packets
>>>  datapath: netlink: support L3 packets
>>>  datapath: add Ethernet push and pop actions
>>>  datapath: allow L3 netdev ports
>>>  userspace: add support for pop_eth and push_eth actions
>>>  userspace: add layer 3 flow and switching support
>>>  userspace: add non-tap (l3) support to GRE vports
>>>  datapath: Add a missing break statement
>>>  datapath: upcall: Fix vlan handling.
>>>  datapath: enable vxlangpe creation in compat mode
>>>  userspace: enable layer3 option for vxlan-gpe
>>>  userspace: add vxlan-gpe support for dpdk netdev
>> 
>> Picking this thread back up, apologies for the delay..
>> 
>> Given that these backports + vlan + other series by Jarno may be 
>> interdependent on each other, I figured that I will assemble a single tree 
>> that brings them all together, run travis and local kmod testing on a 
>> variety of platforms, as well as per-commit compile checks with kernels 4.9 
>> and 3.13.
>> 
>> Here's the current tree I'm testing:
>> https://github.com/joestringer/openvswitch/commits/dev/backport_review_v0.6
>> 
>> Travis looks good (build check against a range of kernels):
>> https://travis-ci.org/joestringer/openvswitch/builds/206841787
>> 
>> My local system-kmod testing on a variety of platforms is coming out looking 
>> good so far.
>> 
>> I dropped the userspace changes since they are decoupled and superseded. 
>> Where they were necessary to fix the build, I folded in the minimal changes 
>> necessary to fix the patch so that the tree successfully compiles on each 
>> individual commit.
>> 
>> I'd appreciate if you could look over that tree once more, there's a couple 
>> of new patches that 

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

[Joe Stringer]

Thanks for looking it over, that sounds reasonable. I'll be looking
forward along the other backports to try to get us back in better sync
with upstream.

I will mention that at this stage, the tree that I pointed to is
missing the MPLS GSO backport but everything else should be up to date
until the end of the L3 tunnelling series. I'll follow up on the MPLS
GSO thread regarding that[0].

[0] http://patchwork.ozlabs.org/patch/725891/

On 1 March 2017 at 20:23, Yang, Yi Y <yi.y.y...@intel.com> wrote:
> Joe, I checked this tree 
> https://github.com/joestringer/openvswitch/commits/dev/backport_review_v0.6 , 
> it included all the 802.1ad patches and Jiri's l3 kernel data path patches, 
> so I think this is the first step we should take, once they are officially 
> merged, Jan and I will rework userspace l3 patches and vxlangpe patches and 
> resubmit them based on your tree.
>
> -Original Message-
> From: Joe Stringer [mailto:j...@ovn.org]
> Sent: Thursday, March 2, 2017 11:43 AM
> To: Yang, Yi Y <yi.y.y...@intel.com>
> Cc: ovs dev <d...@openvswitch.org>; Jarno Rajahalme <ja...@ovn.org>
> Subject: Re: [ovs-dev] [PATCH v3 00/16] port Jiri Benc's L3 patchset to ovs
>
> On 6 February 2017 at 05:04, Yi Yang <yi.y.y...@intel.com> wrote:
>> This patch set just ports Jiri Benc's L3 8 support patches for layer 3 
>> encapsulated packets from net-next to current ovs, it also includes Jiri 
>> Benc's 3 userspace patches, Jarno Rajahalme and Pravin Shelar's vlan fix 
>> patches for L3 patchset as well as my 3 patches which enabled vxlangpe in 
>> compat mode and dpdk netdev in both L2 and L3(layer3=true) mode.
>>
>> This patchset has been verified on Ubuntu 14.04 x86_64 with Linux kernel 
>> 3.13.0-24-generic and 4.9.7, it also passed "make check"
>> and "sudo make check-kmod RECHECK=yes" in Fedora 23 with kernel
>> 4.2.3-300.fc23.x86_64
>>
>> This patch set is based on 
>> https://mail.openvswitch.org/pipermail/ovs-dev/2017-February/328492.html 
>> ([PATCH v2 0/4] Backport 802.1ad patches), please merge this one after 
>> merging [PATCH v2 0/4] Backport 802.1ad patches.
>>
>> Yi Yang (16):
>>   datapath: use hard_header_len instead of hardcoded ETH_HLEN
>>   datapath: add mac_proto field to the flow key
>>   datapath: pass mac_proto to ovs_vport_send
>>   datapath: support MPLS push and pop for L3 packets
>>   datapath: add processing of L3 packets
>>   datapath: netlink: support L3 packets
>>   datapath: add Ethernet push and pop actions
>>   datapath: allow L3 netdev ports
>>   userspace: add support for pop_eth and push_eth actions
>>   userspace: add layer 3 flow and switching support
>>   userspace: add non-tap (l3) support to GRE vports
>>   datapath: Add a missing break statement
>>   datapath: upcall: Fix vlan handling.
>>   datapath: enable vxlangpe creation in compat mode
>>   userspace: enable layer3 option for vxlan-gpe
>>   userspace: add vxlan-gpe support for dpdk netdev
>
> Picking this thread back up, apologies for the delay..
>
> Given that these backports + vlan + other series by Jarno may be 
> interdependent on each other, I figured that I will assemble a single tree 
> that brings them all together, run travis and local kmod testing on a variety 
> of platforms, as well as per-commit compile checks with kernels 4.9 and 3.13.
>
> Here's the current tree I'm testing:
> https://github.com/joestringer/openvswitch/commits/dev/backport_review_v0.6
>
> Travis looks good (build check against a range of kernels):
> https://travis-ci.org/joestringer/openvswitch/builds/206841787
>
> My local system-kmod testing on a variety of platforms is coming out looking 
> good so far.
>
> I dropped the userspace changes since they are decoupled and superseded. 
> Where they were necessary to fix the build, I folded in the minimal changes 
> necessary to fix the patch so that the tree successfully compiles on each 
> individual commit.
>
> I'd appreciate if you could look over that tree once more, there's a couple 
> of new patches that I backported but otherwise it's all series that have been 
> out on the mailinglist over the past few weeks. I folded a few fixes together 
> so that the tree should not break in between commits. I also updated the 
> formatting of each commit message to unsure that, for example, attribution is 
> retained from the original commits. Given they're building fine and testing 
> looks good, I'd like to move towards pushing these patches, and then I can 
> continue with the next series of backports review.
>
> New commits:
> https://github.com/joestringer/openvswitch/commit/8fa9841b9b06139f69f0138868ed9d6df730b748
> https://github.com/joestringer/openvswitch/commit/c598981830e1274391fb80bae6ca9862e6c53fda
>
> Where I made changes to the posted patches, I updated the commit message to 
> include [Committer notes].
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

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

[Yang, Yi Y]

Joe, I checked this tree 
https://github.com/joestringer/openvswitch/commits/dev/backport_review_v0.6 , 
it included all the 802.1ad patches and Jiri's l3 kernel data path patches, so 
I think this is the first step we should take, once they are officially merged, 
Jan and I will rework userspace l3 patches and vxlangpe patches and resubmit 
them based on your tree.

-Original Message-
From: Joe Stringer [mailto:j...@ovn.org] 
Sent: Thursday, March 2, 2017 11:43 AM
To: Yang, Yi Y <yi.y.y...@intel.com>
Cc: ovs dev <d...@openvswitch.org>; Jarno Rajahalme <ja...@ovn.org>
Subject: Re: [ovs-dev] [PATCH v3 00/16] port Jiri Benc's L3 patchset to ovs

On 6 February 2017 at 05:04, Yi Yang <yi.y.y...@intel.com> wrote:
> This patch set just ports Jiri Benc's L3 8 support patches for layer 3 
> encapsulated packets from net-next to current ovs, it also includes Jiri 
> Benc's 3 userspace patches, Jarno Rajahalme and Pravin Shelar's vlan fix 
> patches for L3 patchset as well as my 3 patches which enabled vxlangpe in 
> compat mode and dpdk netdev in both L2 and L3(layer3=true) mode.
>
> This patchset has been verified on Ubuntu 14.04 x86_64 with Linux kernel 
> 3.13.0-24-generic and 4.9.7, it also passed "make check"
> and "sudo make check-kmod RECHECK=yes" in Fedora 23 with kernel
> 4.2.3-300.fc23.x86_64
>
> This patch set is based on 
> https://mail.openvswitch.org/pipermail/ovs-dev/2017-February/328492.html 
> ([PATCH v2 0/4] Backport 802.1ad patches), please merge this one after 
> merging [PATCH v2 0/4] Backport 802.1ad patches.
>
> Yi Yang (16):
>   datapath: use hard_header_len instead of hardcoded ETH_HLEN
>   datapath: add mac_proto field to the flow key
>   datapath: pass mac_proto to ovs_vport_send
>   datapath: support MPLS push and pop for L3 packets
>   datapath: add processing of L3 packets
>   datapath: netlink: support L3 packets
>   datapath: add Ethernet push and pop actions
>   datapath: allow L3 netdev ports
>   userspace: add support for pop_eth and push_eth actions
>   userspace: add layer 3 flow and switching support
>   userspace: add non-tap (l3) support to GRE vports
>   datapath: Add a missing break statement
>   datapath: upcall: Fix vlan handling.
>   datapath: enable vxlangpe creation in compat mode
>   userspace: enable layer3 option for vxlan-gpe
>   userspace: add vxlan-gpe support for dpdk netdev

Picking this thread back up, apologies for the delay..

Given that these backports + vlan + other series by Jarno may be interdependent 
on each other, I figured that I will assemble a single tree that brings them 
all together, run travis and local kmod testing on a variety of platforms, as 
well as per-commit compile checks with kernels 4.9 and 3.13.

Here's the current tree I'm testing:
https://github.com/joestringer/openvswitch/commits/dev/backport_review_v0.6

Travis looks good (build check against a range of kernels):
https://travis-ci.org/joestringer/openvswitch/builds/206841787

My local system-kmod testing on a variety of platforms is coming out looking 
good so far.

I dropped the userspace changes since they are decoupled and superseded. Where 
they were necessary to fix the build, I folded in the minimal changes necessary 
to fix the patch so that the tree successfully compiles on each individual 
commit.

I'd appreciate if you could look over that tree once more, there's a couple of 
new patches that I backported but otherwise it's all series that have been out 
on the mailinglist over the past few weeks. I folded a few fixes together so 
that the tree should not break in between commits. I also updated the 
formatting of each commit message to unsure that, for example, attribution is 
retained from the original commits. Given they're building fine and testing 
looks good, I'd like to move towards pushing these patches, and then I can 
continue with the next series of backports review.

New commits:
https://github.com/joestringer/openvswitch/commit/8fa9841b9b06139f69f0138868ed9d6df730b748
https://github.com/joestringer/openvswitch/commit/c598981830e1274391fb80bae6ca9862e6c53fda

Where I made changes to the posted patches, I updated the commit message to 
include [Committer notes].
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

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

[Joe Stringer]

On 6 February 2017 at 05:04, Yi Yang  wrote:
> This patch set just ports Jiri Benc's L3 8 support patches for layer 3 
> encapsulated packets from net-next to current ovs, it also includes Jiri 
> Benc's 3 userspace patches, Jarno Rajahalme and Pravin Shelar's vlan fix 
> patches for L3 patchset as well as my 3 patches which enabled vxlangpe in 
> compat mode and dpdk netdev in both L2 and L3(layer3=true) mode.
>
> This patchset has been verified on Ubuntu 14.04 x86_64 with Linux kernel 
> 3.13.0-24-generic and 4.9.7, it also passed "make check"
> and "sudo make check-kmod RECHECK=yes" in Fedora 23 with kernel
> 4.2.3-300.fc23.x86_64
>
> This patch set is based on 
> https://mail.openvswitch.org/pipermail/ovs-dev/2017-February/328492.html 
> ([PATCH v2 0/4] Backport 802.1ad patches), please merge this one after 
> merging [PATCH v2 0/4] Backport 802.1ad patches.
>
> Yi Yang (16):
>   datapath: use hard_header_len instead of hardcoded ETH_HLEN
>   datapath: add mac_proto field to the flow key
>   datapath: pass mac_proto to ovs_vport_send
>   datapath: support MPLS push and pop for L3 packets
>   datapath: add processing of L3 packets
>   datapath: netlink: support L3 packets
>   datapath: add Ethernet push and pop actions
>   datapath: allow L3 netdev ports
>   userspace: add support for pop_eth and push_eth actions
>   userspace: add layer 3 flow and switching support
>   userspace: add non-tap (l3) support to GRE vports
>   datapath: Add a missing break statement
>   datapath: upcall: Fix vlan handling.
>   datapath: enable vxlangpe creation in compat mode
>   userspace: enable layer3 option for vxlan-gpe
>   userspace: add vxlan-gpe support for dpdk netdev

Picking this thread back up, apologies for the delay..

Given that these backports + vlan + other series by Jarno may be
interdependent on each other, I figured that I will assemble a single
tree that brings them all together, run travis and local kmod testing
on a variety of platforms, as well as per-commit compile checks with
kernels 4.9 and 3.13.

Here's the current tree I'm testing:
https://github.com/joestringer/openvswitch/commits/dev/backport_review_v0.6

Travis looks good (build check against a range of kernels):
https://travis-ci.org/joestringer/openvswitch/builds/206841787

My local system-kmod testing on a variety of platforms is coming out looking
good so far.

I dropped the userspace changes since they are decoupled and
superseded. Where they were necessary to fix the build, I folded in
the minimal changes necessary to fix the patch so that the tree
successfully compiles on each individual commit.

I'd appreciate if you could look over that tree once more, there's a
couple of new patches that I backported but otherwise it's all series
that have been out on the mailinglist over the past few weeks. I
folded a few fixes together so that the tree should not break in
between commits. I also updated the formatting of each commit message to
unsure that, for example, attribution is retained from the original
commits. Given they're building fine and testing looks good, I'd like
to move towards pushing these patches, and then I can continue with
the next series of backports review.

New commits:
https://github.com/joestringer/openvswitch/commit/8fa9841b9b06139f69f0138868ed9d6df730b748
https://github.com/joestringer/openvswitch/commit/c598981830e1274391fb80bae6ca9862e6c53fda

Where I made changes to the posted patches, I updated the commit
message to include [Committer notes].
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

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

[Valentine Sinitsyn]

Hi Jan,

On 10.02.2017 04:14, Jan Scheurich wrote:

Hi Valentine,

On 2017-02-09 08:58, Valentine Sinitsyn wrote:

This L3 patchset looks similar to what we did internally with OVS 2.6
to add support for IPv6 tunnels.

Could you please confirm that ovs-dpctl reports correct statistics
with this patchset when one uses in-kernel Linux datapath? We had some
issues with this (the counters were always zero). Largely, this was
because userspace code (I refer to the tools and the daemon, not DPDK
datapath here) assumes a plugged network interface is always L2, and I
don't see this patch touching these files.


The most recent user-space code in vswitchd that deals with the L3
tunnels in netdev and kernel datapath is contained in another patch
series:
https://mail.openvswitch.org/pipermail/ovs-dev/2017-February/328391.html

You could help in reviewing that. It may not be complete with respect to
handling kernel datapath tunnels as we were not able to test yet due to
a lack of patches to configure L3 tunnel ports in the kernel. But
similar problems with counters might also exist with netdev datapath.
I had a quick look at patch series, thanks for the links. Will try to 
have a more in-depth look this week.


As for the "counters issue" I mentioned, it seems tiny given the scope 
of the patchset. Moreover, a get_etheraddr() change in [1] should fix 
it, although I haven't checked yet.


[1] https://mail.openvswitch.org/pipermail/ovs-dev/2017-February/328392.html

Best,
Valentine



Thanks, Jan


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

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

[Yang, Yi Y]

Joe, got it, thanks a lot.

-Original Message-
From: Joe Stringer [mailto:j...@ovn.org] 
Sent: Saturday, February 11, 2017 5:38 AM
To: Yang, Yi Y <yi.y.y...@intel.com>
Cc: Multanen, Eric W <eric.w.multa...@intel.com>; ovs dev 
<d...@openvswitch.org>; Yi-Hung Wei <yihung@gmail.com>
Subject: Re: [ovs-dev] [PATCH v3 00/16] port Jiri Benc's L3 patchset to ovs

On 9 February 2017 at 17:45, Yang, Yi Y <yi.y.y...@intel.com> wrote:
> Joe, thank you for explanation, let us push 802.1ad backport patches first, 
> Eric Garver has acked two of them, I'll rework another one patch he 
> commented. What Valentine mentioned has no business with 802.1 ad, it is what 
> we want to consider after Eric Garver's rtnetlink userspace patches are 
> merged, we have no way to use in-kernel data path to do it without rtnetlink 
> userspace patches.
>
> Can you point out which patches  for 802.1ad are missing? I almost checked 
> all the 802.1 ad patches, ovs doesn't use most of them, most of them make 
> nonsense to ovs. Eric, please help point out if I missed something.

I believe there's "net: mpls: Fixups for GSO" and one other more trivial one. 
I've been working with Yi-Hung to try to figure out those backports, so we 
should be able to proceed with those shortly, then I'll look at 802.1ad.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

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

[Yang, Yi Y]

Eric and Joe, thank you so much for your verification and fix, I'll resubmit a 
new version including this fix and missing part.

-Original Message-
From: Eric Garver [mailto:e...@erig.me] 
Sent: Saturday, February 11, 2017 9:22 PM
To: Joe Stringer <j...@ovn.org>; Yang, Yi Y <yi.y.y...@intel.com>
Cc: ovs dev <d...@openvswitch.org>
Subject: Re: [ovs-dev] [PATCH v3 00/16] port Jiri Benc's L3 patchset to ovs

On Fri, Feb 10, 2017 at 01:33:04PM -0800, Joe Stringer wrote:
> On 10 February 2017 at 12:25, Eric Garver <e...@erig.me> wrote:
> > On Fri, Feb 10, 2017 at 11:24:58AM -0500, Eric Garver wrote:
> >> On Tue, Feb 07, 2017 at 02:30:46PM -0800, Joe Stringer wrote:
> >> > On 7 February 2017 at 09:44, Joe Stringer <j...@ovn.org> wrote:
> >> > > On 6 February 2017 at 16:46, Yang, Yi Y <yi.y.y...@intel.com> wrote:
> >> > >> Joe, I checked current ovs and net-next kernel, obviously some 
> >> > >> patches from net-next are selectively backported to ovs, but others 
> >> > >> are not, I'm not sure what the policy is for a new patch. It will be 
> >> > >> better that the person who did the patch backports it to ovs at the 
> >> > >> same time, but nobody did so.
> >> > >
> >> > > That's supposed to be the policy; However, depending on the 
> >> > > patch sometimes openvswitch isn't even the main target of the 
> >> > > change, so the contributor may not be aware they should do so. 
> >> > > There may be added difficulty if the previous contributor 
> >> > > didn't do their backport. I think that lately there hasn't been 
> >> > > particularly close co-ordination between the trees, but ideally 
> >> > > I think that as we approach an OVS release, we would try to sync them 
> >> > > up.
> >> > >
> >> > >> My 802.1ad backport has included all the things l3 patch set 
> >> > >> depends on, so I think you can give it a go :-)
> >> > >
> >> > > Kicking off a build on my local tester, I can at least report 
> >> > > back on that. I see you've tested on a few platforms as well, that's 
> >> > > great.
> >> >
> >> > Reporting back, I suspect that some of the older kernels don't 
> >> > treat the double-tagged vlans right with this series?
> >> >
> >> > I was using an Ubuntu trusty VM with kernel 3.13.0-92-generic 
> >> > plus this backport and it seems to be consistently failing this test:
> >> >
> >> > 4: datapath - ping between two ports on cvlan FAILED 
> >> > (system-traffic.at:88)
> >> >
> >> > The test output just shows that a ping tries about 10 times and 
> >> > fails all of the times. I didn't investigate further.
> >>
> >> Hi Joe,
> >>
> >> Thanks for testing those backports.
> >>
> >> I ran them on debian with 3.16 kernel. I see the same failures.
> >> Interestingly, if when the test hangs (when waiting on the ping) I 
> >> ping in a different window namespace to namespace it will work as expected.
> >> This ping should be equivalent to what the test is doing. I can't 
> >> explain this yet, but I'll keep investigating.
> >
> > I found the cause. The upcall re-inserts the VLAN back into the raw 
> > packet data, but the TPID is hard coded to 0x8100.
> > This affects kernels for which HAVE_VLAN_INSERT_TAG_SET_PROTO is not 
> > set.
> >
> > The below patch allows the cvlan and 802.ad tests (not upstream yet) 
> > to pass on debian with 3.16 kernel. However, it may be better 
> > backport a modern version of vlan_insert_tag_set_proto().
> 
> Thanks for figuring this out. Will you or Yi submit this?

I think it makes sense for it to be submitted with the 802.1ad series.

Yi,

Can you add the fix I suggest above to your 802.1ad series?
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

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

[Joe Stringer]

On 10 February 2017 at 12:25, Eric Garver  wrote:
> On Fri, Feb 10, 2017 at 11:24:58AM -0500, Eric Garver wrote:
>> On Tue, Feb 07, 2017 at 02:30:46PM -0800, Joe Stringer wrote:
>> > On 7 February 2017 at 09:44, Joe Stringer  wrote:
>> > > On 6 February 2017 at 16:46, Yang, Yi Y  wrote:
>> > >> Joe, I checked current ovs and net-next kernel, obviously some patches 
>> > >> from net-next are selectively backported to ovs, but others are not, 
>> > >> I'm not sure what the policy is for a new patch. It will be better that 
>> > >> the person who did the patch backports it to ovs at the same time, but 
>> > >> nobody did so.
>> > >
>> > > That's supposed to be the policy; However, depending on the patch
>> > > sometimes openvswitch isn't even the main target of the change, so the
>> > > contributor may not be aware they should do so. There may be added
>> > > difficulty if the previous contributor didn't do their backport. I
>> > > think that lately there hasn't been particularly close co-ordination
>> > > between the trees, but ideally I think that as we approach an OVS
>> > > release, we would try to sync them up.
>> > >
>> > >> My 802.1ad backport has included all the things l3 patch set depends 
>> > >> on, so I think you can give it a go :-)
>> > >
>> > > Kicking off a build on my local tester, I can at least report back on
>> > > that. I see you've tested on a few platforms as well, that's great.
>> >
>> > Reporting back, I suspect that some of the older kernels don't treat
>> > the double-tagged vlans right with this series?
>> >
>> > I was using an Ubuntu trusty VM with kernel 3.13.0-92-generic plus
>> > this backport and it seems to be consistently failing this test:
>> >
>> > 4: datapath - ping between two ports on cvlan FAILED (system-traffic.at:88)
>> >
>> > The test output just shows that a ping tries about 10 times and fails
>> > all of the times. I didn't investigate further.
>>
>> Hi Joe,
>>
>> Thanks for testing those backports.
>>
>> I ran them on debian with 3.16 kernel. I see the same failures.
>> Interestingly, if when the test hangs (when waiting on the ping) I ping
>> in a different window namespace to namespace it will work as expected.
>> This ping should be equivalent to what the test is doing. I can't
>> explain this yet, but I'll keep investigating.
>
> I found the cause. The upcall re-inserts the VLAN back into the raw
> packet data, but the TPID is hard coded to 0x8100.
> This affects kernels for which HAVE_VLAN_INSERT_TAG_SET_PROTO is not
> set.
>
> The below patch allows the cvlan and 802.ad tests (not upstream yet) to
> pass on debian with 3.16 kernel. However, it may be better backport a
> modern version of vlan_insert_tag_set_proto().

Thanks for figuring this out. Will you or Yi submit this?
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

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

[Eric Garver]

On Tue, Feb 07, 2017 at 02:30:46PM -0800, Joe Stringer wrote:
> On 7 February 2017 at 09:44, Joe Stringer  wrote:
> > On 6 February 2017 at 16:46, Yang, Yi Y  wrote:
> >> Joe, I checked current ovs and net-next kernel, obviously some patches 
> >> from net-next are selectively backported to ovs, but others are not, I'm 
> >> not sure what the policy is for a new patch. It will be better that the 
> >> person who did the patch backports it to ovs at the same time, but nobody 
> >> did so.
> >
> > That's supposed to be the policy; However, depending on the patch
> > sometimes openvswitch isn't even the main target of the change, so the
> > contributor may not be aware they should do so. There may be added
> > difficulty if the previous contributor didn't do their backport. I
> > think that lately there hasn't been particularly close co-ordination
> > between the trees, but ideally I think that as we approach an OVS
> > release, we would try to sync them up.
> >
> >> My 802.1ad backport has included all the things l3 patch set depends on, 
> >> so I think you can give it a go :-)
> >
> > Kicking off a build on my local tester, I can at least report back on
> > that. I see you've tested on a few platforms as well, that's great.
> 
> Reporting back, I suspect that some of the older kernels don't treat
> the double-tagged vlans right with this series?
> 
> I was using an Ubuntu trusty VM with kernel 3.13.0-92-generic plus
> this backport and it seems to be consistently failing this test:
> 
> 4: datapath - ping between two ports on cvlan FAILED (system-traffic.at:88)
> 
> The test output just shows that a ping tries about 10 times and fails
> all of the times. I didn't investigate further.

Hi Joe,

Thanks for testing those backports.

I ran them on debian with 3.16 kernel. I see the same failures.
Interestingly, if when the test hangs (when waiting on the ping) I ping
in a different window namespace to namespace it will work as expected.
This ping should be equivalent to what the test is doing. I can't
explain this yet, but I'll keep investigating.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

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

[Yang, Yi Y]

Joe, thank you for explanation, let us push 802.1ad backport patches first, 
Eric Garver has acked two of them, I'll rework another one patch he commented. 
What Valentine mentioned has no business with 802.1 ad, it is what we want to 
consider after Eric Garver's rtnetlink userspace patches are merged, we have no 
way to use in-kernel data path to do it without rtnetlink userspace patches.

Can you point out which patches  for 802.1ad are missing? I almost checked all 
the 802.1 ad patches, ovs doesn't use most of them, most of them make nonsense 
to ovs. Eric, please help point out if I missed something.

-Original Message-
From: Joe Stringer [mailto:j...@ovn.org] 
Sent: Friday, February 10, 2017 8:01 AM
To: Yang, Yi Y <yi.y.y...@intel.com>
Cc: ovs dev <d...@openvswitch.org>; Yi-Hung Wei <yihung@gmail.com>
Subject: Re: [ovs-dev] [PATCH v3 00/16] port Jiri Benc's L3 patchset to ovs

On 8 February 2017 at 18:50, Yang, Yi Y <yi.y.y...@intel.com> wrote:
> Then, are you merging 
> https://mail.openvswitch.org/pipermail/ovs-dev/2017-February/328492.html or 
> do I need to do anything else for it?

It looks like the backport breaks the existing kernel module tests on older 
kernels, without even using the new functionality. I've provided feedback on 
how you might further dig into that, and I don't believe I've seen confirmation 
that you observe the same thing, or any proposed solutions.

I've mentioned previously a preference to see patches backported in the 
canonical order. I believe there's just a few patches missing from before 
802.1ad, and discussions are ongoing to address those backports. I expect with 
time, those will be proposed and merged, and then we can look at 802.1ad.

Finally, patches always need review before merging. Given that others in the 
community have previously looked into 802.1ad, I was looking to see that people 
with more detailed knowledge of these codepaths would take a first look. I see 
that Eric has now done so, and there is feedback to address. I also see that 
Valentine has provided some feedback.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

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

[Yang, Yi Y]

Ok, let me push 802.1 ad backport patches first.

-Original Message-
From: Jan Scheurich [mailto:jan.scheur...@web.de] 
Sent: Friday, February 10, 2017 7:04 AM
To: Yang, Yi Y <yi.y.y...@intel.com>; Jan Scheurich 
<jan.scheur...@ericsson.com>; Joe Stringer <j...@ovn.org>; Jiri Benc 
(jb...@redhat.com) <jb...@redhat.com>; Eric Garver <e...@erig.me>; 
'ja...@ovn.org' <ja...@ovn.org>
Cc: d...@openvswitch.org
Subject: Re: [ovs-dev] [PATCH v3 00/16] port Jiri Benc's L3 patchset to ovs

Hi Yi,

I suggest we include (adapted versions of) your vxlan-gpe user space patches 
into the new L3 tunneling user-space series when we respin v2 with the review 
comments. Thus we get rid of one dependency. And you can focus on the datapath 
backports and NSH. Do you agree?

@Jarno: It would be great if you could find the time to review the new series.

Thanks, Jan

On 2017-02-09 11:46, Yang, Yi Y wrote:
> 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.scheur...@ericsson.com]
> Sent: Thursday, February 9, 2017 5:50 PM
> To: Yang, Yi Y <yi.y.y...@intel.com>; Joe Stringer <j...@ovn.org>; Jiri 
> Benc (jb...@redhat.com) <jb...@redhat.com>; Eric Garver <e...@erig.me>
> Cc: d...@openvswitch.org; Jarno Rajahalme (ja...@ovn.org) 
> <ja...@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.y...@intel.com]
>> Sent: Wednesday, 08 February, 2017 06:31
>> To: Jan Scheurich <jan.scheur...@ericsson.com>; Joe Stringer 
>> <j...@ovn.org>; Jiri Benc (jb...@redhat.com) <jb...@redhat.com>; Eric 
>> Garver <e...@erig.me>
>> Cc: d...@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.scheur...@ericsson.com]
>> Sent: Wednesday, February 8, 2017 7:19 AM
>> To: Joe Stringer <j...@ovn.org>; Yang, Yi Y <yi.y.y...@intel.com>; 
>> Jiri Benc (jb...@redhat.com) <jb...@redhat.com>; Eric Garver 
>> <e...@erig.me>
>> Cc: d...@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:j...@ovn.org]
>>> Sent: Tuesday, 07 February, 2017 18:55
>>> To:

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

[Joe Stringer]

On 8 February 2017 at 18:50, Yang, Yi Y  wrote:
> Then, are you merging 
> https://mail.openvswitch.org/pipermail/ovs-dev/2017-February/328492.html or 
> do I need to do anything else for it?

It looks like the backport breaks the existing kernel module tests on
older kernels, without even using the new functionality. I've provided
feedback on how you might further dig into that, and I don't believe
I've seen confirmation that you observe the same thing, or any
proposed solutions.

I've mentioned previously a preference to see patches backported in
the canonical order. I believe there's just a few patches missing from
before 802.1ad, and discussions are ongoing to address those
backports. I expect with time, those will be proposed and merged, and
then we can look at 802.1ad.

Finally, patches always need review before merging. Given that others
in the community have previously looked into 802.1ad, I was looking to
see that people with more detailed knowledge of these codepaths would
take a first look. I see that Eric has now done so, and there is
feedback to address. I also see that Valentine has provided some
feedback.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

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

[Jan Scheurich]

Hi Valentine,

On 2017-02-09 08:58, Valentine Sinitsyn wrote:
This L3 patchset looks similar to what we did internally with OVS 2.6 
to add support for IPv6 tunnels.


Could you please confirm that ovs-dpctl reports correct statistics 
with this patchset when one uses in-kernel Linux datapath? We had some 
issues with this (the counters were always zero). Largely, this was 
because userspace code (I refer to the tools and the daemon, not DPDK 
datapath here) assumes a plugged network interface is always L2, and I 
don't see this patch touching these files.


The most recent user-space code in vswitchd that deals with the L3 
tunnels in netdev and kernel datapath is contained in another patch 
series: 
https://mail.openvswitch.org/pipermail/ovs-dev/2017-February/328391.html


You could help in reviewing that. It may not be complete with respect to 
handling kernel datapath tunnels as we were not able to test yet due to 
a lack of patches to configure L3 tunnel ports in the kernel. But 
similar problems with counters might also exist with netdev datapath.


Thanks, Jan

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

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

[Jan Scheurich]

Hi Yi,

I suggest we include (adapted versions of) your vxlan-gpe user space 
patches into the new L3 tunneling user-space series when we respin v2 
with the review comments. Thus we get rid of one dependency. And you can 
focus on the datapath backports and NSH. Do you agree?


@Jarno: It would be great if you could find the time to review the new 
series.


Thanks, Jan

On 2017-02-09 11:46, Yang, Yi Y wrote:

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.scheur...@ericsson.com]
Sent: Thursday, February 9, 2017 5:50 PM
To: Yang, Yi Y <yi.y.y...@intel.com>; Joe Stringer <j...@ovn.org>; Jiri Benc 
(jb...@redhat.com) <jb...@redhat.com>; Eric Garver <e...@erig.me>
Cc: d...@openvswitch.org; Jarno Rajahalme (ja...@ovn.org) <ja...@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.y...@intel.com]
Sent: Wednesday, 08 February, 2017 06:31
To: Jan Scheurich <jan.scheur...@ericsson.com>; Joe Stringer
<j...@ovn.org>; Jiri Benc (jb...@redhat.com) <jb...@redhat.com>; Eric
Garver <e...@erig.me>
Cc: d...@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.scheur...@ericsson.com]
Sent: Wednesday, February 8, 2017 7:19 AM
To: Joe Stringer <j...@ovn.org>; Yang, Yi Y <yi.y.y...@intel.com>; Jiri
Benc (jb...@redhat.com) <jb...@redhat.com>; Eric Garver <e...@erig.me>
Cc: d...@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:j...@ovn.org]
Sent: Tuesday, 07 February, 2017 18:55
To: Yang, Yi Y <yi.y.y...@intel.com>
Cc: Jan Scheurich <jan.scheur...@ericsson.com>; d...@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.y...@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.

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


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

Re: [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.scheur...@ericsson.com] 
Sent: Thursday, February 9, 2017 5:50 PM
To: Yang, Yi Y <yi.y.y...@intel.com>; Joe Stringer <j...@ovn.org>; Jiri Benc 
(jb...@redhat.com) <jb...@redhat.com>; Eric Garver <e...@erig.me>
Cc: d...@openvswitch.org; Jarno Rajahalme (ja...@ovn.org) <ja...@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.y...@intel.com]
> Sent: Wednesday, 08 February, 2017 06:31
> To: Jan Scheurich <jan.scheur...@ericsson.com>; Joe Stringer 
> <j...@ovn.org>; Jiri Benc (jb...@redhat.com) <jb...@redhat.com>; Eric 
> Garver <e...@erig.me>
> Cc: d...@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.scheur...@ericsson.com]
> Sent: Wednesday, February 8, 2017 7:19 AM
> To: Joe Stringer <j...@ovn.org>; Yang, Yi Y <yi.y.y...@intel.com>; Jiri 
> Benc (jb...@redhat.com) <jb...@redhat.com>; Eric Garver <e...@erig.me>
> Cc: d...@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:j...@ovn.org]
> > Sent: Tuesday, 07 February, 2017 18:55
> > To: Yang, Yi Y <yi.y.y...@intel.com>
> > Cc: Jan Scheurich <jan.scheur...@ericsson.com>; d...@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.y...@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.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

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

[Jan Scheurich]

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.y...@intel.com]
> Sent: Wednesday, 08 February, 2017 06:31
> To: Jan Scheurich <jan.scheur...@ericsson.com>; Joe Stringer <j...@ovn.org>; 
> Jiri Benc (jb...@redhat.com) <jb...@redhat.com>; Eric
> Garver <e...@erig.me>
> Cc: d...@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.scheur...@ericsson.com]
> Sent: Wednesday, February 8, 2017 7:19 AM
> To: Joe Stringer <j...@ovn.org>; Yang, Yi Y <yi.y.y...@intel.com>; Jiri Benc 
> (jb...@redhat.com) <jb...@redhat.com>; Eric Garver
> <e...@erig.me>
> Cc: d...@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:j...@ovn.org]
> > Sent: Tuesday, 07 February, 2017 18:55
> > To: Yang, Yi Y <yi.y.y...@intel.com>
> > Cc: Jan Scheurich <jan.scheur...@ericsson.com>; d...@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.y...@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.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

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

[Valentine Sinitsyn]

Hi all,

This L3 patchset looks similar to what we did internally with OVS 2.6 to 
add support for IPv6 tunnels.


Could you please confirm that ovs-dpctl reports correct statistics with 
this patchset when one uses in-kernel Linux datapath? We had some issues 
with this (the counters were always zero). Largely, this was because 
userspace code (I refer to the tools and the daemon, not DPDK datapath 
here) assumes a plugged network interface is always L2, and I don't see 
this patch touching these files.


Thanks for your co-operation.

Best regards,
Valentine Sinitsyn
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

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

[Yang, Yi Y]

Then, are you merging 
https://mail.openvswitch.org/pipermail/ovs-dev/2017-February/328492.html or do 
I need to do anything else for it?

-Original Message-
From: Joe Stringer [mailto:j...@ovn.org] 
Sent: Thursday, February 9, 2017 9:44 AM
To: Yang, Yi Y <yi.y.y...@intel.com>
Cc: ovs dev <d...@openvswitch.org>; Yi-Hung Wei <yihung@gmail.com>
Subject: Re: [ovs-dev] [PATCH v3 00/16] port Jiri Benc's L3 patchset to ovs

On 7 February 2017 at 21:15, Yang, Yi Y <yi.y.y...@intel.com> wrote:
> Joe, I investigated all the patches which changed 
> include/linux/if_vlan.h for 802.1ad in net-next again, I found ovs 
> compat mode doesn't need most of them at all, 
> datapath/linux/compat/include/linux/ only includes part of changes 
> which aren't in local  $KSRC/include/linux/ but required in 
> datapath/linux/compat/*.c

^ required in datapath/linux/compat/*.c, or datapath/*.c. If a function doesn't 
exist in an older kernel, a backport is needed - whether in the headers or 
datapath/linux/compat/*.c. Also, if the behaviour of one of those functions 
changes on a newer kernel which requires changes to the users (such as 
datapath/*.c), then they may also need updating.

> , so my conclusion is we needn't them at all, 
> https://mail.openvswitch.org/pipermail/ovs-dev/2017-February/328492.html is 
> enough for 802.1ad backport for ovs.

At a glance I think you're right.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

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

[Joe Stringer]

On 7 February 2017 at 21:15, Yang, Yi Y  wrote:
> Joe, I investigated all the patches which changed include/linux/if_vlan.h for 
> 802.1ad in net-next again, I found ovs compat mode doesn't need most of them 
> at all, datapath/linux/compat/include/linux/ only includes part of changes 
> which aren't in local  $KSRC/include/linux/ but required in 
> datapath/linux/compat/*.c

^ required in datapath/linux/compat/*.c, or datapath/*.c. If a
function doesn't exist in an older kernel, a backport is needed -
whether in the headers or datapath/linux/compat/*.c. Also, if the
behaviour of one of those functions changes on a newer kernel which
requires changes to the users (such as datapath/*.c), then they may
also need updating.

> , so my conclusion is we needn't them at all, 
> https://mail.openvswitch.org/pipermail/ovs-dev/2017-February/328492.html is 
> enough for 802.1ad backport for ovs.

At a glance I think you're right.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

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

[Joe Stringer]

On 7 February 2017 at 20:55, Yang, Yi  wrote:
> On Tue, Feb 07, 2017 at 02:30:46PM -0800, Joe Stringer wrote:
>> On 7 February 2017 at 09:44, Joe Stringer  wrote:
>> > On 6 February 2017 at 16:46, Yang, Yi Y  wrote:
>> >> Joe, I checked current ovs and net-next kernel, obviously some patches 
>> >> from net-next are selectively backported to ovs, but others are not, I'm 
>> >> not sure what the policy is for a new patch. It will be better that the 
>> >> person who did the patch backports it to ovs at the same time, but nobody 
>> >> did so.
>> >
>> > That's supposed to be the policy; However, depending on the patch
>> > sometimes openvswitch isn't even the main target of the change, so the
>> > contributor may not be aware they should do so. There may be added
>> > difficulty if the previous contributor didn't do their backport. I
>> > think that lately there hasn't been particularly close co-ordination
>> > between the trees, but ideally I think that as we approach an OVS
>> > release, we would try to sync them up.
>> >
>> >> My 802.1ad backport has included all the things l3 patch set depends on, 
>> >> so I think you can give it a go :-)
>> >
>> > Kicking off a build on my local tester, I can at least report back on
>> > that. I see you've tested on a few platforms as well, that's great.
>>
>> Reporting back, I suspect that some of the older kernels don't treat
>> the double-tagged vlans right with this series?
>>
>> I was using an Ubuntu trusty VM with kernel 3.13.0-92-generic plus
>> this backport and it seems to be consistently failing this test:
>>
>> 4: datapath - ping between two ports on cvlan FAILED (system-traffic.at:88)
>>
>> The test output just shows that a ping tries about 10 times and fails
>> all of the times. I didn't investigate further.
>
> But unfortunately I can't run "make check-kmod" on Ubuntu 14.04, all the
> cases are failed, how do you know I can run "datapath - ping between two
> ports on cvlan" manually by one-by-one shell commands?

I'm not sure what's preventing you (I do this frequently), but this is
a good question:

You can find the test in tests/system-traffic:

$ git grep "ping between two ports on cv"
tests/system-traffic.at:AT_SETUP([datapath - ping between two ports on cvlan])

If we open that up in an editor, we can see the progression of the test:
https://github.com/openvswitch/ovs/blob/40c7b2fc0d181155ea87a962a522d48f4166370b/tests/system-traffic.at#L72

First, there's OVS_TRAFFIC_VSWITCHD_START(). This pretty much just
starts up OVS. You can trace this definition through
tests/system-kmod-macros.at and tests/ofproto-macros.at.

We can see lines like AT_CHECK(...) which run a command and check the
return code.

A bunch of the ADD_foo(...) commands will set up the environment in a
particular way; create namespaces, ports, vlans, etc. These are
typically defined in tests/system-kmod-macros.at or
tests/system-common-macros.at.

OVS_WAIT_UNTIL(...) will try running the command a few times, but if
it doesn't return successfully within about 10 seconds the test will
fail with something like "hard failure" (in the test logs).

NS_CHECK_EXEC(...) will run a command within a particular network
namespace and check the return condition, similar to AT_CHECK().

Finally, the test finishes by shutting down OVS -
OVS_TRAFFIC_VSWITCHD_STOP and doing autotest cleanup - AT_CLEANUP.

For this specific test, you can see that it pretty much sets up a
couple of namespaces, connects them to OVS with veth pairs, then adds
additional VLAN devices within those namespaces, which should go over
the OVS. There's three different IP ranges used for bare traffic,
single-tagged, and double-tagged. The failure I see is happening at
the OVS_WAIT_UNTIL() line, so the double-tagged VLANs never show any
connectivity. Later commands will test different packet sizes, but it
doesn't even get that far.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

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

[Yang, Yi Y]

Joe, I investigated all the patches which changed include/linux/if_vlan.h for 
802.1ad in net-next again, I found ovs compat mode doesn't need most of them at 
all, datapath/linux/compat/include/linux/ only includes part of changes which 
aren't in local  $KSRC/include/linux/ but required in 
datapath/linux/compat/*.c, so my conclusion is we needn't them at all, 
https://mail.openvswitch.org/pipermail/ovs-dev/2017-February/328492.html is 
enough for 802.1ad backport for ovs.

-Original Message-
From: Joe Stringer [mailto:j...@ovn.org] 
Sent: Wednesday, February 8, 2017 6:31 AM
To: Yang, Yi Y <yi.y.y...@intel.com>
Cc: ovs dev <d...@openvswitch.org>; Yi-Hung Wei <yihung@gmail.com>
Subject: Re: [ovs-dev] [PATCH v3 00/16] port Jiri Benc's L3 patchset to ovs

On 7 February 2017 at 09:44, Joe Stringer <j...@ovn.org> wrote:
> On 6 February 2017 at 16:46, Yang, Yi Y <yi.y.y...@intel.com> wrote:
>> Joe, I checked current ovs and net-next kernel, obviously some patches from 
>> net-next are selectively backported to ovs, but others are not, I'm not sure 
>> what the policy is for a new patch. It will be better that the person who 
>> did the patch backports it to ovs at the same time, but nobody did so.
>
> That's supposed to be the policy; However, depending on the patch 
> sometimes openvswitch isn't even the main target of the change, so the 
> contributor may not be aware they should do so. There may be added 
> difficulty if the previous contributor didn't do their backport. I 
> think that lately there hasn't been particularly close co-ordination 
> between the trees, but ideally I think that as we approach an OVS 
> release, we would try to sync them up.
>
>> My 802.1ad backport has included all the things l3 patch set depends 
>> on, so I think you can give it a go :-)
>
> Kicking off a build on my local tester, I can at least report back on 
> that. I see you've tested on a few platforms as well, that's great.

Reporting back, I suspect that some of the older kernels don't treat the 
double-tagged vlans right with this series?

I was using an Ubuntu trusty VM with kernel 3.13.0-92-generic plus this 
backport and it seems to be consistently failing this test:

4: datapath - ping between two ports on cvlan FAILED (system-traffic.at:88)

The test output just shows that a ping tries about 10 times and fails all of 
the times. I didn't investigate further.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

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

[Yang, Yi]

On Tue, Feb 07, 2017 at 02:30:46PM -0800, Joe Stringer wrote:
> On 7 February 2017 at 09:44, Joe Stringer  wrote:
> > On 6 February 2017 at 16:46, Yang, Yi Y  wrote:
> >> Joe, I checked current ovs and net-next kernel, obviously some patches 
> >> from net-next are selectively backported to ovs, but others are not, I'm 
> >> not sure what the policy is for a new patch. It will be better that the 
> >> person who did the patch backports it to ovs at the same time, but nobody 
> >> did so.
> >
> > That's supposed to be the policy; However, depending on the patch
> > sometimes openvswitch isn't even the main target of the change, so the
> > contributor may not be aware they should do so. There may be added
> > difficulty if the previous contributor didn't do their backport. I
> > think that lately there hasn't been particularly close co-ordination
> > between the trees, but ideally I think that as we approach an OVS
> > release, we would try to sync them up.
> >
> >> My 802.1ad backport has included all the things l3 patch set depends on, 
> >> so I think you can give it a go :-)
> >
> > Kicking off a build on my local tester, I can at least report back on
> > that. I see you've tested on a few platforms as well, that's great.
> 
> Reporting back, I suspect that some of the older kernels don't treat
> the double-tagged vlans right with this series?
> 
> I was using an Ubuntu trusty VM with kernel 3.13.0-92-generic plus
> this backport and it seems to be consistently failing this test:
> 
> 4: datapath - ping between two ports on cvlan FAILED (system-traffic.at:88)
> 
> The test output just shows that a ping tries about 10 times and fails
> all of the times. I didn't investigate further.

But unfortunately I can't run "make check-kmod" on Ubuntu 14.04, all the
cases are failed, how do you know I can run "datapath - ping between two
ports on cvlan" manually by one-by-one shell commands?
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

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

[Jan Scheurich]

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:j...@ovn.org]
> Sent: Tuesday, 07 February, 2017 18:55
> To: Yang, Yi Y <yi.y.y...@intel.com>
> Cc: Jan Scheurich <jan.scheur...@ericsson.com>; d...@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.y...@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.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

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

[Joe Stringer]

On 7 February 2017 at 09:44, Joe Stringer  wrote:
> On 6 February 2017 at 16:46, Yang, Yi Y  wrote:
>> Joe, I checked current ovs and net-next kernel, obviously some patches from 
>> net-next are selectively backported to ovs, but others are not, I'm not sure 
>> what the policy is for a new patch. It will be better that the person who 
>> did the patch backports it to ovs at the same time, but nobody did so.
>
> That's supposed to be the policy; However, depending on the patch
> sometimes openvswitch isn't even the main target of the change, so the
> contributor may not be aware they should do so. There may be added
> difficulty if the previous contributor didn't do their backport. I
> think that lately there hasn't been particularly close co-ordination
> between the trees, but ideally I think that as we approach an OVS
> release, we would try to sync them up.
>
>> My 802.1ad backport has included all the things l3 patch set depends on, so 
>> I think you can give it a go :-)
>
> Kicking off a build on my local tester, I can at least report back on
> that. I see you've tested on a few platforms as well, that's great.

Reporting back, I suspect that some of the older kernels don't treat
the double-tagged vlans right with this series?

I was using an Ubuntu trusty VM with kernel 3.13.0-92-generic plus
this backport and it seems to be consistently failing this test:

4: datapath - ping between two ports on cvlan FAILED (system-traffic.at:88)

The test output just shows that a ping tries about 10 times and fails
all of the times. I didn't investigate further.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

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

[Joe Stringer]

On 7 February 2017 at 05:28, Yang, Yi Y  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.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

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

[Joe Stringer]

On 6 February 2017 at 16:46, Yang, Yi Y  wrote:
> Joe, I checked current ovs and net-next kernel, obviously some patches from 
> net-next are selectively backported to ovs, but others are not, I'm not sure 
> what the policy is for a new patch. It will be better that the person who did 
> the patch backports it to ovs at the same time, but nobody did so.

That's supposed to be the policy; However, depending on the patch
sometimes openvswitch isn't even the main target of the change, so the
contributor may not be aware they should do so. There may be added
difficulty if the previous contributor didn't do their backport. I
think that lately there hasn't been particularly close co-ordination
between the trees, but ideally I think that as we approach an OVS
release, we would try to sync them up.

> My 802.1ad backport has included all the things l3 patch set depends on, so I 
> think you can give it a go :-)

Kicking off a build on my local tester, I can at least report back on
that. I see you've tested on a few platforms as well, that's great. If
you were able to add even one or two basic tests to the
system-kmod-testsuite for the new L3 bits (eg, set up a tunnel and
send some packets through it), that would sure go some way towards
knowing that this series does what it intends without bad
side-effects, and also would help us to catch any potential
regressions.

> To make sure 802.1ad to work, there is still a userspace work to do, but as 
> Pravin said, this has no business with l3 patch set.

Sure thing, userspace can be decoupled.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

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

[Yang, Yi Y]

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. 

-Original Message-
From: Jan Scheurich [mailto:jan.scheur...@ericsson.com] 
Sent: Tuesday, February 7, 2017 6:50 PM
To: Yang, Yi Y <yi.y.y...@intel.com>; d...@openvswitch.org
Cc: Zoltán Balogh <zoltan.bal...@ericsson.com>; Jarno Rajahalme (ja...@ovn.org) 
<ja...@ovn.org>
Subject: RE: [ovs-dev] [PATCH v3 00/16] port Jiri Benc's L3 patchset to ovs

Hi Yi,

Three of the user-space patches of your series have been superseded by our new 
patch series [PATCH 0/7] userspace: Support for L3 tunneling:
https://mail.openvswitch.org/pipermail/ovs-dev/2017-February/328391.html

Please remove them from the next version.
The user-space patches for VXLAN-GPE tunnels need adaptation to the above L3 
tunneling patch set.

BR, Jan

> Yi Yang (16):
>   datapath: use hard_header_len instead of hardcoded ETH_HLEN
>   datapath: add mac_proto field to the flow key
>   datapath: pass mac_proto to ovs_vport_send
>   datapath: support MPLS push and pop for L3 packets
>   datapath: add processing of L3 packets
>   datapath: netlink: support L3 packets
>   datapath: add Ethernet push and pop actions
>   datapath: allow L3 netdev ports
>   userspace: add support for pop_eth and push_eth actions
Jan: This is superseded

>   userspace: add layer 3 flow and switching support
Jan: This is superseded

>   userspace: add non-tap (l3) support to GRE vports
Jan: This is superseded

>   datapath: Add a missing break statement
>   datapath: upcall: Fix vlan handling.
>   datapath: enable vxlangpe creation in compat mode
>   userspace: enable layer3 option for vxlan-gpe
Jan: To be adapted to 
https://mail.openvswitch.org/pipermail/ovs-dev/2017-February/328391.html 

>   userspace: add vxlan-gpe support for dpdk netdev
Jan: To be adapted to 
https://mail.openvswitch.org/pipermail/ovs-dev/2017-February/328391.html 
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

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

[Yang, Yi Y]

Joe, I checked current ovs and net-next kernel, obviously some patches from 
net-next are selectively backported to ovs, but others are not, I'm not sure 
what the policy is for a new patch. It will be better that the person who did 
the patch backports it to ovs at the same time, but nobody did so.

My 802.1ad backport has included all the things l3 patch set depends on, so I 
think you can give it a go :-)

To make sure 802.1ad to work, there is still a userspace work to do, but as 
Pravin said, this has no business with l3 patch set.

-Original Message-
From: Joe Stringer [mailto:j...@ovn.org] 
Sent: Tuesday, February 7, 2017 8:34 AM
To: Yang, Yi Y <yi.y.y...@intel.com>
Cc: ovs dev <d...@openvswitch.org>; Yi-Hung Wei <yihung@gmail.com>
Subject: Re: [ovs-dev] [PATCH v3 00/16] port Jiri Benc's L3 patchset to ovs

On 6 February 2017 at 05:04, Yi Yang <yi.y.y...@intel.com> wrote:
> This patch set just ports Jiri Benc's L3 8 support patches for layer 3 
> encapsulated packets from net-next to current ovs, it also includes Jiri 
> Benc's 3 userspace patches, Jarno Rajahalme and Pravin Shelar's vlan fix 
> patches for L3 patchset as well as my 3 patches which enabled vxlangpe in 
> compat mode and dpdk netdev in both L2 and L3(layer3=true) mode.
>
> This patchset has been verified on Ubuntu 14.04 x86_64 with Linux kernel 
> 3.13.0-24-generic and 4.9.7, it also passed "make check"
> and "sudo make check-kmod RECHECK=yes" in Fedora 23 with kernel
> 4.2.3-300.fc23.x86_64
>
> This patch set is based on 
> https://mail.openvswitch.org/pipermail/ovs-dev/2017-February/328492.html 
> ([PATCH v2 0/4] Backport 802.1ad patches), please merge this one after 
> merging [PATCH v2 0/4] Backport 802.1ad patches.

Thanks for this work! I think that this comprises the majority of the remaining 
diff between the backport and the upstream tree, though there are still a bunch 
of other unrelated changes that are still missing.

As we discussed earlier, it'd be good to ensure that we don't miss any of the 
small patches as well; to avoid this, my expectation would be that we can apply 
backports of all of the missing patches from net-next in the order they were 
applied to net-next. I believe that Yi-Hung is interested at looking at 
backporting those other missing patches up until the 802.1ad changes. From 
there we can review the 802.1ad backport series you have posted, then continue 
backporting up until the L3 tunnelling backport you've proposed.  I'm not 
really sure how much work is involved in this at the moment, although I think 
that 802.1ad and L3 tunnelling were the largest features.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

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

[Joe Stringer]

On 6 February 2017 at 05:04, Yi Yang  wrote:
> This patch set just ports Jiri Benc's L3 8 support patches for layer 3 
> encapsulated packets from net-next to current ovs, it also includes Jiri 
> Benc's 3 userspace patches, Jarno Rajahalme and Pravin Shelar's vlan fix 
> patches for L3 patchset as well as my 3 patches which enabled vxlangpe in 
> compat mode and dpdk netdev in both L2 and L3(layer3=true) mode.
>
> This patchset has been verified on Ubuntu 14.04 x86_64 with Linux kernel 
> 3.13.0-24-generic and 4.9.7, it also passed "make check"
> and "sudo make check-kmod RECHECK=yes" in Fedora 23 with kernel
> 4.2.3-300.fc23.x86_64
>
> This patch set is based on 
> https://mail.openvswitch.org/pipermail/ovs-dev/2017-February/328492.html 
> ([PATCH v2 0/4] Backport 802.1ad patches), please merge this one after 
> merging [PATCH v2 0/4] Backport 802.1ad patches.

Thanks for this work! I think that this comprises the majority of the
remaining diff between the backport and the upstream tree, though
there are still a bunch of other unrelated changes that are still
missing.

As we discussed earlier, it'd be good to ensure that we don't miss any
of the small patches as well; to avoid this, my expectation would be
that we can apply backports of all of the missing patches from
net-next in the order they were applied to net-next. I believe that
Yi-Hung is interested at looking at backporting those other missing
patches up until the 802.1ad changes. From there we can review the
802.1ad backport series you have posted, then continue backporting up
until the L3 tunnelling backport you've proposed.  I'm not really sure
how much work is involved in this at the moment, although I think that
802.1ad and L3 tunnelling were the largest features.
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev