Re: [ovs-dev] [PATCH v3 00/16] port Jiri Benc's L3 patchset to ovs
> On Mar 2, 2017, at 11:56 AM, Joe Stringer 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 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 >> Cc: ovs dev ; Jarno Rajahalme >> 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 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 o
Re: [ovs-dev] [PATCH v3 00/16] port Jiri Benc's L3 patchset to ovs
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 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 > Cc: ovs dev ; Jarno Rajahalme > 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 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, 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 Cc: ovs dev ; Jarno Rajahalme 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 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
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
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
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 Cc: Multanen, Eric W ; ovs dev ; Yi-Hung Wei 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 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
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 ; Yang, Yi Y Cc: ovs dev 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 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? 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
On Fri, Feb 10, 2017 at 01:33:04PM -0800, Joe Stringer wrote: > 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? 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
On 9 February 2017 at 17:45, Yang, Yi Y 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
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
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(). diff --git a/datapath/linux/compat/include/linux/if_vlan.h b/datapath/linux/compat/include/linux/if_vlan.h index ff55fb8641b9..a3a25df46248 100644 --- a/datapath/linux/compat/include/linux/if_vlan.h +++ b/datapath/linux/compat/include/linux/if_vlan.h @@ -24,8 +24,9 @@ * acceptable. */ #define vlan_insert_tag_set_proto(skb, proto, vlan_tci) \ - rpl_vlan_insert_tag_set_proto(skb, vlan_tci) + rpl_vlan_insert_tag_set_proto(skb, proto, vlan_tci) static inline struct sk_buff *rpl_vlan_insert_tag_set_proto(struct sk_buff *skb, + __be16 vlan_proto, u16 vlan_tci) { struct vlan_ethhdr *veth; @@ -41,12 +42,12 @@ static inline struct sk_buff *rpl_vlan_insert_tag_set_proto(struct sk_buff *skb, skb->mac_header -= VLAN_HLEN; /* first, the ethernet type */ - veth->h_vlan_proto = htons(ETH_P_8021Q); + veth->h_vlan_proto = vlan_proto; /* now, the TCI */ veth->h_vlan_TCI = htons(vlan_tci); - skb->protocol = htons(ETH_P_8021Q); + skb->protocol = vlan_proto; return skb; } ___ 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
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
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 Cc: ovs dev ; Yi-Hung Wei 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 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
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 ; Jan Scheurich ; Joe Stringer ; Jiri Benc (jb...@redhat.com) ; Eric Garver ; '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 ; Joe Stringer ; Jiri > Benc (jb...@redhat.com) ; Eric Garver > Cc: d...@openvswitch.org; Jarno Rajahalme (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 ; Joe Stringer >> ; Jiri Benc (jb...@redhat.com) ; Eric >> Garver >> 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 ; Yang, Yi Y ; >> Jiri Benc (jb...@redhat.com) ; Eric Garver >> >> 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 >>> Cc: Jan Scheurich ; 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 wrote: >>>> Jan, I know that, but per Joe's comments, it seems he won't merge your >>>>
Re: [ovs-dev] [PATCH v3 00/16] port Jiri Benc's L3 patchset to ovs
If rtnetlink user space patches aren't merged, I don't think you can use in-kernel data path correctly, yes there are some work to do, but that has to been done after Eric Garver's rtnetlink user space patches are merged. Maybe you can try RFC patches Eric Garver posted https://mail.openvswitch.org/pipermail/ovs-dev/2017-January/327749.html, -Original Message- From: ovs-dev-boun...@openvswitch.org [mailto:ovs-dev-boun...@openvswitch.org] On Behalf Of Valentine Sinitsyn Sent: Thursday, February 9, 2017 3:58 PM To: ovs-dev@openvswitch.org Subject: Re: [ovs-dev] [PATCH v3 00/16] port Jiri Benc's L3 patchset to ovs 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 ___ 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
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
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
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 ; Joe Stringer ; Jiri Benc (jb...@redhat.com) ; Eric Garver Cc: d...@openvswitch.org; Jarno Rajahalme (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 ; Joe Stringer ; Jiri Benc (jb...@redhat.com) ; Eric Garver 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 ; Yang, Yi Y ; Jiri Benc (jb...@redhat.com) ; Eric Garver 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 Cc: Jan Scheurich ; 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 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
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 ; Joe Stringer ; Jiri Benc (jb...@redhat.com) ; Eric Garver Cc: d...@openvswitch.org; Jarno Rajahalme (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 ; Joe Stringer > ; Jiri Benc (jb...@redhat.com) ; Eric > Garver > 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 ; Yang, Yi Y ; Jiri > Benc (jb...@redhat.com) ; Eric Garver > 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 > > Cc: Jan Scheurich ; 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 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
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 ; Joe Stringer ; > Jiri Benc (jb...@redhat.com) ; Eric > Garver > 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 ; Yang, Yi Y ; Jiri Benc > (jb...@redhat.com) ; Eric Garver > > 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 > > Cc: Jan Scheurich ; 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 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
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
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 Cc: ovs dev ; Yi-Hung Wei 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 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
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
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
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 ; Yang, Yi Y ; Jiri Benc (jb...@redhat.com) ; Eric Garver 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 > Cc: Jan Scheurich ; 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 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, 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 Cc: ovs dev ; Yi-Hung Wei 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 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
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
I mean these userspace patches are necessary to run l3 tunnel port in compat mode and dpdk netdev mode. Only jiri's 8 patches backport is not enough. One feasible way is we can rebase Jan's patches on top of this patch set. -Original Message- From: Joe Stringer [mailto:j...@ovn.org] Sent: Wednesday, February 8, 2017 1:55 AM To: Yang, Yi Y Cc: Jan Scheurich ; 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 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
Good point, I will add a following patch to do this. -Original Message- From: Joe Stringer [mailto:j...@ovn.org] Sent: Wednesday, February 8, 2017 1:44 AM To: Yang, Yi Y Cc: ovs dev ; Yi-Hung Wei Subject: Re: [ovs-dev] [PATCH v3 00/16] port Jiri Benc's L3 patchset to ovs 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
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 > Cc: Jan Scheurich ; 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 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
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
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
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
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 ; d...@openvswitch.org Cc: Zoltán Balogh ; Jarno Rajahalme (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
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
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 Cc: ovs dev ; Yi-Hung Wei 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 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
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
[ovs-dev] [PATCH v3 00/16] port Jiri Benc's L3 patchset to ovs
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 acinclude.m4 | 1 + build-aux/extract-ofp-fields | 1 + datapath/actions.c| 111 --- datapath/datapath.c | 13 -- datapath/flow.c | 113 --- datapath/flow.h | 22 +++ datapath/flow_netlink.c | 177 +++-- datapath/linux/compat/include/linux/openvswitch.h | 18 ++ datapath/linux/compat/include/linux/skbuff.h | 5 + datapath/linux/compat/skbuff-openvswitch.c| 8 +- datapath/vport-netdev.c | 9 +- datapath/vport-vxlan.c| 15 ++ datapath/vport.c | 31 ++- datapath/vport.h | 2 +- include/openvswitch/automake.mk | 3 +- include/openvswitch/flow.h| 23 ++- include/openvswitch/match.h | 1 + include/openvswitch/meta-flow.h | 9 +- include/openvswitch/ofp-print.h | 8 +- include/openvswitch/vxlangpe.h| 80 lib/dp-packet.h | 14 +- lib/dpif-netdev.c | 6 +- lib/dpif-netlink.c| 4 + lib/dpif.c| 9 +- lib/flow.c| 132 + lib/flow.h| 11 ++ lib/match.c | 13 +- lib/meta-flow.c | 2 + lib/netdev-bsd.c | 2 + lib/netdev-dummy.c| 1 + lib/netdev-linux.c| 5 +- lib/netdev-native-tnl.c | 85 +++- lib/netdev-vport.c| 34 +++- lib/netdev.h | 1 + lib/nx-match.c| 2 +- lib/odp-execute.c | 20 ++ lib/odp-util.c| 227 ++ lib/odp-util.h| 4 +- lib/ofp-print.c | 27 ++- lib/ofp-util.c| 2 +- lib/packets.c | 35 lib/packets.h | 6 + lib/tnl-ports.c | 49 +++-- lib/tnl-ports.h | 3 +- ofproto/ofproto-dpif-rid.h| 2 +- ofproto/ofproto-dpif-sflow.c | 8 + ofproto/ofproto-dpif-xlate.c | 29 ++- ofproto/ofproto-dpif-xlate.h | 2 +- ofproto/ofproto-dpif.c| 4 +- ofproto/tunnel.c | 4 +- tests/ofproto-dpif.at | 6 +- tests/tunnel-push-pop-ipv6.at | 22 ++- tests/tunnel-push-pop.at | 38 +++- tests/tunnel.at | 10 +- vswitchd/vswitch.xml | 13 ++ 55 files changed, 1166 insertions(+),