| Message ID | 1515657217-105285-1-git-send-email-yi.y.yang@intel.com |
|---|---|
| Headers | show |
| Series | datapath: enable NSH support in kernel compat mode | expand |
On 1/10/2018 11:53 PM, Yi Yang wrote: > This patch series is to backport NSH support patches in Linux net-next tree > to OVS in order that it can support NSH in kernel compat mode. > > Yi Yang (5): > datapath: ether: add NSH ethertype > datapath: vxlan: factor out VXLAN-GPE next protocol > datapath: net: add NSH header structures and helpers > datapath: nsh: add GSO support > datapath: enable NSH support > > NEWS | 1 + > datapath/Modules.mk | 4 +- > datapath/actions.c | 116 ++++++++ > datapath/datapath.c | 4 + > datapath/flow.c | 51 ++++ > datapath/flow.h | 7 + > datapath/flow_netlink.c | 343 +++++++++++++++++++++- > datapath/flow_netlink.h | 5 + > datapath/linux/Modules.mk | 2 + > datapath/linux/compat/include/linux/if_ether.h | 4 + > datapath/linux/compat/include/linux/openvswitch.h | 6 +- > datapath/linux/compat/include/net/nsh.h | 313 ++++++++++++++++++++ > datapath/linux/compat/include/net/tun_proto.h | 49 ++++ > datapath/linux/compat/include/net/vxlan.h | 6 - > datapath/linux/compat/vxlan.c | 32 +- > datapath/nsh.c | 142 +++++++++ > 16 files changed, 1048 insertions(+), 37 deletions(-) > create mode 100644 datapath/linux/compat/include/net/nsh.h > create mode 100644 datapath/linux/compat/include/net/tun_proto.h > create mode 100644 datapath/nsh.c > Hi Yi, My apologies for the delay in reviewing this series. I've finished up my review and I think it mostly looks pretty good but I did find an issue compiling on a 3.10.107 kernel build: CC [M] /home/travis/build/gvrose8192/ovs-experimental/datapath/linux/vport-netdev.o /home/travis/build/gvrose8192/ovs-experimental/datapath/linux/nsh.c:108:17: error: undefined identifier 'skb_gso_error_unwind' CC [M] /home/travis/build/gvrose8192/ovs-experimental/datapath/linux/nsh.o /home/travis/build/gvrose8192/ovs-experimental/datapath/linux/nsh.c: In function ‘nsh_gso_segment’: /home/travis/build/gvrose8192/ovs-experimental/datapath/linux/nsh.c:108:3: error: implicit declaration of function ‘skb_gso_error_unwind’ [-Werror=implicit-function-declaration] skb_gso_error_unwind(skb, htons(ETH_P_NSH), nsh_len, ^ cc1: some warnings being treated as errors make[3]: *** [/home/travis/build/gvrose8192/ovs-experimental/datapath/linux/nsh.o] Error 1 make[3]: *** Waiting for unfinished jobs.... make[2]: *** [_module_/home/travis/build/gvrose8192/ovs-experimental/datapath/linux] Error 2 make[2]: Leaving directory `/home/travis/build/gvrose8192/ovs-experimental/linux-3.10.107' make[1]: *** [default] Error 2 make[1]: Leaving directory `/home/travis/build/gvrose8192/ovs-experimental/datapath/linux' make: *** [all-recursive] Error 1 So we'll need to fix that up and I also think the patches will need to be rebased to current master. That second part is my fault... so sorry again about that. One other thing, I ran this through our standard 'make check and make check-kmod' tests and everything was fine so the patches don't seem break anything. I'm still concerned though that the test coverage probably didn't hit any parts of your code. I'm wondering if there is some way I can test the code path and get some test coverage there. Could you write up a self test for the tests/system-traffic.at kernel test? Of if that's not practical is there some other way I could test this code? Thanks, - Greg
Greg, thank you so much for your reviewing, which Linux distribution version has linux-3.10.107 kernel? I’ll add a test case for kernel datapath, fix compiling issue on linux-3.10.107 and rebase it to master.
From: Gregory Rose [mailto:gvrose8192@gmail.com]
Sent: Tuesday, January 30, 2018 1:51 AM
To: Yang, Yi Y <yi.y.yang@intel.com>; dev@openvswitch.org
Cc: blp@ovn.org; jan.scheurich@ericsson.com
Subject: Re: [PATCH v1 0/5] datapath: enable NSH support in kernel compat mode
On 1/10/2018 11:53 PM, Yi Yang wrote:
This patch series is to backport NSH support patches in Linux net-next tree
to OVS in order that it can support NSH in kernel compat mode.
Yi Yang (5):
datapath: ether: add NSH ethertype
datapath: vxlan: factor out VXLAN-GPE next protocol
datapath: net: add NSH header structures and helpers
datapath: nsh: add GSO support
datapath: enable NSH support
NEWS | 1 +
datapath/Modules.mk | 4 +-
datapath/actions.c | 116 ++++++++
datapath/datapath.c | 4 +
datapath/flow.c | 51 ++++
datapath/flow.h | 7 +
datapath/flow_netlink.c | 343 +++++++++++++++++++++-
datapath/flow_netlink.h | 5 +
datapath/linux/Modules.mk | 2 +
datapath/linux/compat/include/linux/if_ether.h | 4 +
datapath/linux/compat/include/linux/openvswitch.h | 6 +-
datapath/linux/compat/include/net/nsh.h | 313 ++++++++++++++++++++
datapath/linux/compat/include/net/tun_proto.h | 49 ++++
datapath/linux/compat/include/net/vxlan.h | 6 -
datapath/linux/compat/vxlan.c | 32 +-
datapath/nsh.c | 142 +++++++++
16 files changed, 1048 insertions(+), 37 deletions(-)
create mode 100644 datapath/linux/compat/include/net/nsh.h
create mode 100644 datapath/linux/compat/include/net/tun_proto.h
create mode 100644 datapath/nsh.c
Hi Yi,
My apologies for the delay in reviewing this series.
I've finished up my review and I think it mostly looks pretty good but I did find an issue compiling on a 3.10.107 kernel build:
CC [M] /home/travis/build/gvrose8192/ovs-experimental/datapath/linux/vport-netdev.o
/home/travis/build/gvrose8192/ovs-experimental/datapath/linux/nsh.c:108:17: error: undefined identifier 'skb_gso_error_unwind'
CC [M] /home/travis/build/gvrose8192/ovs-experimental/datapath/linux/nsh.o
/home/travis/build/gvrose8192/ovs-experimental/datapath/linux/nsh.c: In function ‘nsh_gso_segment’:
/home/travis/build/gvrose8192/ovs-experimental/datapath/linux/nsh.c:108:3: error: implicit declaration of function ‘skb_gso_error_unwind’ [-Werror=implicit-function-declaration]
skb_gso_error_unwind(skb, htons(ETH_P_NSH), nsh_len,
^
cc1: some warnings being treated as errors
make[3]: *** [/home/travis/build/gvrose8192/ovs-experimental/datapath/linux/nsh.o] Error 1
make[3]: *** Waiting for unfinished jobs....
make[2]: *** [_module_/home/travis/build/gvrose8192/ovs-experimental/datapath/linux] Error 2
make[2]: Leaving directory `/home/travis/build/gvrose8192/ovs-experimental/linux-3.10.107'
make[1]: *** [default] Error 2
make[1]: Leaving directory `/home/travis/build/gvrose8192/ovs-experimental/datapath/linux'
make: *** [all-recursive] Error 1
So we'll need to fix that up and I also think the patches will need to be rebased to current master. That second part is my fault... so sorry again about that.
One other thing, I ran this through our standard 'make check and make check-kmod' tests and everything was fine so the patches don't seem break anything. I'm still concerned though that the test coverage probably didn't hit any parts of your code. I'm wondering if there is some way I can test the code path and get some test coverage there. Could you write up a self test for the tests/system-traffic.at kernel test? Of if that's not practical is there some other way I could test this code?
Thanks,
- Greg
Hi, Greg
I installed linux 3.10.107 in Ubuntu 14.04 and fixed skb_gso_error_unwind issue, but for unit test, tests/system-layer3-tunnels.at is a good reference for it because we used vxlan-gpe for nsh, I ran unit test 90, but it always fails (I have installed and used net-next kernel and the latest iproute2)
Here is error log
./system-layer3-tunnels.at:25: ip netns exec at_ns0 sh << NS_EXEC_HEREDOC
ip route add 10.1.1.2/32 encap ip id 0 dst 172.31.1.100 dev at_vxlan1
NS_EXEC_HEREDOC
--- /dev/null 2018-01-30 02:18:43.272647961 +0000
+++ /home/vagrant/ovs-nsh-test/tests/system-kmod-testsuite.dir/at-groups/90/stderr 2018-01-30 09:45:15.415934534 +0000
@@ -0,0 +1 @@
+RTNETLINK answers: Operation not supported
./system-layer3-tunnels.at:25: exit code was 2, expected 0
I think my system missed something so “ip route add 10.1.1.2/32 encap ip id 0 dst 172.31.1.100 dev at_vxlan1
“ failed, Eric, what linux distribution do you know I can run “ping over VXLAN-GPE” successfully, I’ll use it as baseline to add NSH unit test for kernel data path.
From: Gregory Rose [mailto:gvrose8192@gmail.com]
Sent: Tuesday, January 30, 2018 1:51 AM
To: Yang, Yi Y <yi.y.yang@intel.com>; dev@openvswitch.org
Cc: blp@ovn.org; jan.scheurich@ericsson.com
Subject: Re: [PATCH v1 0/5] datapath: enable NSH support in kernel compat mode
On 1/10/2018 11:53 PM, Yi Yang wrote:
This patch series is to backport NSH support patches in Linux net-next tree
to OVS in order that it can support NSH in kernel compat mode.
Yi Yang (5):
datapath: ether: add NSH ethertype
datapath: vxlan: factor out VXLAN-GPE next protocol
datapath: net: add NSH header structures and helpers
datapath: nsh: add GSO support
datapath: enable NSH support
NEWS | 1 +
datapath/Modules.mk | 4 +-
datapath/actions.c | 116 ++++++++
datapath/datapath.c | 4 +
datapath/flow.c | 51 ++++
datapath/flow.h | 7 +
datapath/flow_netlink.c | 343 +++++++++++++++++++++-
datapath/flow_netlink.h | 5 +
datapath/linux/Modules.mk | 2 +
datapath/linux/compat/include/linux/if_ether.h | 4 +
datapath/linux/compat/include/linux/openvswitch.h | 6 +-
datapath/linux/compat/include/net/nsh.h | 313 ++++++++++++++++++++
datapath/linux/compat/include/net/tun_proto.h | 49 ++++
datapath/linux/compat/include/net/vxlan.h | 6 -
datapath/linux/compat/vxlan.c | 32 +-
datapath/nsh.c | 142 +++++++++
16 files changed, 1048 insertions(+), 37 deletions(-)
create mode 100644 datapath/linux/compat/include/net/nsh.h
create mode 100644 datapath/linux/compat/include/net/tun_proto.h
create mode 100644 datapath/nsh.c
Hi Yi,
My apologies for the delay in reviewing this series.
I've finished up my review and I think it mostly looks pretty good but I did find an issue compiling on a 3.10.107 kernel build:
CC [M] /home/travis/build/gvrose8192/ovs-experimental/datapath/linux/vport-netdev.o
/home/travis/build/gvrose8192/ovs-experimental/datapath/linux/nsh.c:108:17: error: undefined identifier 'skb_gso_error_unwind'
CC [M] /home/travis/build/gvrose8192/ovs-experimental/datapath/linux/nsh.o
/home/travis/build/gvrose8192/ovs-experimental/datapath/linux/nsh.c: In function ‘nsh_gso_segment’:
/home/travis/build/gvrose8192/ovs-experimental/datapath/linux/nsh.c:108:3: error: implicit declaration of function ‘skb_gso_error_unwind’ [-Werror=implicit-function-declaration]
skb_gso_error_unwind(skb, htons(ETH_P_NSH), nsh_len,
^
cc1: some warnings being treated as errors
make[3]: *** [/home/travis/build/gvrose8192/ovs-experimental/datapath/linux/nsh.o] Error 1
make[3]: *** Waiting for unfinished jobs....
make[2]: *** [_module_/home/travis/build/gvrose8192/ovs-experimental/datapath/linux] Error 2
make[2]: Leaving directory `/home/travis/build/gvrose8192/ovs-experimental/linux-3.10.107'
make[1]: *** [default] Error 2
make[1]: Leaving directory `/home/travis/build/gvrose8192/ovs-experimental/datapath/linux'
make: *** [all-recursive] Error 1
So we'll need to fix that up and I also think the patches will need to be rebased to current master. That second part is my fault... so sorry again about that.
One other thing, I ran this through our standard 'make check and make check-kmod' tests and everything was fine so the patches don't seem break anything. I'm still concerned though that the test coverage probably didn't hit any parts of your code. I'm wondering if there is some way I can test the code path and get some test coverage there. Could you write up a self test for the tests/system-traffic.at kernel test? Of if that's not practical is there some other way I could test this code?
Thanks,
- Greg
On Tue, Jan 30, 2018 at 11:33:55AM +0000, Yang, Yi Y wrote: > Hi, Greg > > I installed linux 3.10.107 in Ubuntu 14.04 and fixed skb_gso_error_unwind issue, but for unit test, tests/system-layer3-tunnels.at is a good reference for it because we used vxlan-gpe for nsh, I ran unit test 90, but it always fails (I have installed and used net-next kernel and the latest iproute2) > > Here is error log > > ./system-layer3-tunnels.at:25: ip netns exec at_ns0 sh << NS_EXEC_HEREDOC > ip route add 10.1.1.2/32 encap ip id 0 dst 172.31.1.100 dev at_vxlan1 > NS_EXEC_HEREDOC > --- /dev/null 2018-01-30 02:18:43.272647961 +0000 > +++ /home/vagrant/ovs-nsh-test/tests/system-kmod-testsuite.dir/at-groups/90/stderr 2018-01-30 09:45:15.415934534 +0000 > @@ -0,0 +1 @@ > +RTNETLINK answers: Operation not supported > ./system-layer3-tunnels.at:25: exit code was 2, expected 0 > > I think my system missed something so “ip route add 10.1.1.2/32 encap ip id 0 dst 172.31.1.100 dev at_vxlan1 > “ failed, Eric, what linux distribution do you know I can run “ping over VXLAN-GPE” successfully, I’ll use it as baseline to add NSH unit test for kernel data path. When I added the tests it was on RHEL-7.4 with a net-next kernel. It should skip the tests if the installed iproute2 does not have the options for GPE. The error you're seeing likely means your kernel does not have GPE support. VXLAN-GPE first appeared in kernel 4.7. e1e5314de08b ("vxlan: implement GPE") As such, I think the VXLAN-GPE test case should pass on any distro with a 4.7+ kernel. > > From: Gregory Rose [mailto:gvrose8192@gmail.com] > Sent: Tuesday, January 30, 2018 1:51 AM > To: Yang, Yi Y <yi.y.yang@intel.com>; dev@openvswitch.org > Cc: blp@ovn.org; jan.scheurich@ericsson.com > Subject: Re: [PATCH v1 0/5] datapath: enable NSH support in kernel compat mode > > On 1/10/2018 11:53 PM, Yi Yang wrote: > > > This patch series is to backport NSH support patches in Linux net-next tree > > to OVS in order that it can support NSH in kernel compat mode. > > > > Yi Yang (5): > > datapath: ether: add NSH ethertype > > datapath: vxlan: factor out VXLAN-GPE next protocol > > datapath: net: add NSH header structures and helpers > > datapath: nsh: add GSO support > > datapath: enable NSH support > > > > NEWS | 1 + > > datapath/Modules.mk | 4 +- > > datapath/actions.c | 116 ++++++++ > > datapath/datapath.c | 4 + > > datapath/flow.c | 51 ++++ > > datapath/flow.h | 7 + > > datapath/flow_netlink.c | 343 +++++++++++++++++++++- > > datapath/flow_netlink.h | 5 + > > datapath/linux/Modules.mk | 2 + > > datapath/linux/compat/include/linux/if_ether.h | 4 + > > datapath/linux/compat/include/linux/openvswitch.h | 6 +- > > datapath/linux/compat/include/net/nsh.h | 313 ++++++++++++++++++++ > > datapath/linux/compat/include/net/tun_proto.h | 49 ++++ > > datapath/linux/compat/include/net/vxlan.h | 6 - > > datapath/linux/compat/vxlan.c | 32 +- > > datapath/nsh.c | 142 +++++++++ > > 16 files changed, 1048 insertions(+), 37 deletions(-) > > create mode 100644 datapath/linux/compat/include/net/nsh.h > > create mode 100644 datapath/linux/compat/include/net/tun_proto.h > > create mode 100644 datapath/nsh.c > > > > Hi Yi, > > My apologies for the delay in reviewing this series. > > I've finished up my review and I think it mostly looks pretty good but I did find an issue compiling on a 3.10.107 kernel build: > CC [M] /home/travis/build/gvrose8192/ovs-experimental/datapath/linux/vport-netdev.o > /home/travis/build/gvrose8192/ovs-experimental/datapath/linux/nsh.c:108:17: error: undefined identifier 'skb_gso_error_unwind' > CC [M] /home/travis/build/gvrose8192/ovs-experimental/datapath/linux/nsh.o > /home/travis/build/gvrose8192/ovs-experimental/datapath/linux/nsh.c: In function ‘nsh_gso_segment’: > /home/travis/build/gvrose8192/ovs-experimental/datapath/linux/nsh.c:108:3: error: implicit declaration of function ‘skb_gso_error_unwind’ [-Werror=implicit-function-declaration] > skb_gso_error_unwind(skb, htons(ETH_P_NSH), nsh_len, > ^ > cc1: some warnings being treated as errors > make[3]: *** [/home/travis/build/gvrose8192/ovs-experimental/datapath/linux/nsh.o] Error 1 > make[3]: *** Waiting for unfinished jobs.... > make[2]: *** [_module_/home/travis/build/gvrose8192/ovs-experimental/datapath/linux] Error 2 > make[2]: Leaving directory `/home/travis/build/gvrose8192/ovs-experimental/linux-3.10.107' > make[1]: *** [default] Error 2 > make[1]: Leaving directory `/home/travis/build/gvrose8192/ovs-experimental/datapath/linux' > make: *** [all-recursive] Error 1 > > So we'll need to fix that up and I also think the patches will need to be rebased to current master. That second part is my fault... so sorry again about that. > > One other thing, I ran this through our standard 'make check and make check-kmod' tests and everything was fine so the patches don't seem break anything. I'm still concerned though that the test coverage probably didn't hit any parts of your code. I'm wondering if there is some way I can test the code path and get some test coverage there. Could you write up a self test for the tests/system-traffic.at kernel test? Of if that's not practical is there some other way I could test this code? > > Thanks, > > - Greg > > _______________________________________________ > dev mailing list > dev@openvswitch.org > https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Hi, Eric My kernel is 4.13.0-rc6, so I'm very sure it can support vxlan-gpe, I can add vxlan-gpe port without any issue by command line, so I don't know what happened. Greg, I checked unit tests in tests/system-traffic.at and tests/system-layer3-tunnels.at for vxlan and vxlan-gpe, I think they are very tricky, for NSH, they won't work, current test infrastructure can't handle NSH unit test in kernel data path, so I don't think I can add it. I have posted v2 patch series, I have sfc test environment in my machine and have verified kernel data path, my test environment has two vagrant VMs, each one VM starts two containers which play SF roles, end-to-end ping and http are both ok. -----Original Message----- From: Eric Garver [mailto:e@erig.me] Sent: Tuesday, January 30, 2018 9:53 PM To: Yang, Yi Y <yi.y.yang@intel.com> Cc: Gregory Rose <gvrose8192@gmail.com>; dev@openvswitch.org Subject: Re: [ovs-dev] [PATCH v1 0/5] datapath: enable NSH support in kernel compat mode On Tue, Jan 30, 2018 at 11:33:55AM +0000, Yang, Yi Y wrote: > Hi, Greg > > I installed linux 3.10.107 in Ubuntu 14.04 and fixed > skb_gso_error_unwind issue, but for unit test, > tests/system-layer3-tunnels.at is a good reference for it because we > used vxlan-gpe for nsh, I ran unit test 90, but it always fails (I > have installed and used net-next kernel and the latest iproute2) > > Here is error log > > ./system-layer3-tunnels.at:25: ip netns exec at_ns0 sh << > NS_EXEC_HEREDOC ip route add 10.1.1.2/32 encap ip id 0 dst > 172.31.1.100 dev at_vxlan1 NS_EXEC_HEREDOC > --- /dev/null 2018-01-30 02:18:43.272647961 +0000 > +++ /home/vagrant/ovs-nsh-test/tests/system-kmod-testsuite.dir/at-groups/90/stderr 2018-01-30 09:45:15.415934534 +0000 > @@ -0,0 +1 @@ > +RTNETLINK answers: Operation not supported > ./system-layer3-tunnels.at:25: exit code was 2, expected 0 > > I think my system missed something so “ip route add 10.1.1.2/32 encap > ip id 0 dst 172.31.1.100 dev at_vxlan1 “ failed, Eric, what linux distribution do you know I can run “ping over VXLAN-GPE” successfully, I’ll use it as baseline to add NSH unit test for kernel data path. When I added the tests it was on RHEL-7.4 with a net-next kernel. It should skip the tests if the installed iproute2 does not have the options for GPE. The error you're seeing likely means your kernel does not have GPE support. VXLAN-GPE first appeared in kernel 4.7. e1e5314de08b ("vxlan: implement GPE") As such, I think the VXLAN-GPE test case should pass on any distro with a 4.7+ kernel. > > From: Gregory Rose [mailto:gvrose8192@gmail.com] > Sent: Tuesday, January 30, 2018 1:51 AM > To: Yang, Yi Y <yi.y.yang@intel.com>; dev@openvswitch.org > Cc: blp@ovn.org; jan.scheurich@ericsson.com > Subject: Re: [PATCH v1 0/5] datapath: enable NSH support in kernel > compat mode > > On 1/10/2018 11:53 PM, Yi Yang wrote: > > > This patch series is to backport NSH support patches in Linux net-next > tree > > to OVS in order that it can support NSH in kernel compat mode. > > > > Yi Yang (5): > > datapath: ether: add NSH ethertype > > datapath: vxlan: factor out VXLAN-GPE next protocol > > datapath: net: add NSH header structures and helpers > > datapath: nsh: add GSO support > > datapath: enable NSH support > > > > NEWS | 1 + > > datapath/Modules.mk | 4 +- > > datapath/actions.c | 116 ++++++++ > > datapath/datapath.c | 4 + > > datapath/flow.c | 51 ++++ > > datapath/flow.h | 7 + > > datapath/flow_netlink.c | 343 +++++++++++++++++++++- > > datapath/flow_netlink.h | 5 + > > datapath/linux/Modules.mk | 2 + > > datapath/linux/compat/include/linux/if_ether.h | 4 + > > datapath/linux/compat/include/linux/openvswitch.h | 6 +- > > datapath/linux/compat/include/net/nsh.h | 313 ++++++++++++++++++++ > > datapath/linux/compat/include/net/tun_proto.h | 49 ++++ > > datapath/linux/compat/include/net/vxlan.h | 6 - > > datapath/linux/compat/vxlan.c | 32 +- > > datapath/nsh.c | 142 +++++++++ > > 16 files changed, 1048 insertions(+), 37 deletions(-) > > create mode 100644 datapath/linux/compat/include/net/nsh.h > > create mode 100644 datapath/linux/compat/include/net/tun_proto.h > > create mode 100644 datapath/nsh.c > > > > Hi Yi, > > My apologies for the delay in reviewing this series. > > I've finished up my review and I think it mostly looks pretty good but I did find an issue compiling on a 3.10.107 kernel build: > CC [M] > /home/travis/build/gvrose8192/ovs-experimental/datapath/linux/vport-ne > tdev.o > /home/travis/build/gvrose8192/ovs-experimental/datapath/linux/nsh.c:108:17: error: undefined identifier 'skb_gso_error_unwind' > CC [M] > /home/travis/build/gvrose8192/ovs-experimental/datapath/linux/nsh.o > /home/travis/build/gvrose8192/ovs-experimental/datapath/linux/nsh.c: In function ‘nsh_gso_segment’: > /home/travis/build/gvrose8192/ovs-experimental/datapath/linux/nsh.c:10 > 8:3: error: implicit declaration of function ‘skb_gso_error_unwind’ > [-Werror=implicit-function-declaration] > skb_gso_error_unwind(skb, htons(ETH_P_NSH), nsh_len, ^ > cc1: some warnings being treated as errors > make[3]: *** > [/home/travis/build/gvrose8192/ovs-experimental/datapath/linux/nsh.o] > Error 1 > make[3]: *** Waiting for unfinished jobs.... > make[2]: *** > [_module_/home/travis/build/gvrose8192/ovs-experimental/datapath/linux > ] Error 2 > make[2]: Leaving directory `/home/travis/build/gvrose8192/ovs-experimental/linux-3.10.107' > make[1]: *** [default] Error 2 > make[1]: Leaving directory `/home/travis/build/gvrose8192/ovs-experimental/datapath/linux' > make: *** [all-recursive] Error 1 > > So we'll need to fix that up and I also think the patches will need to be rebased to current master. That second part is my fault... so sorry again about that. > > One other thing, I ran this through our standard 'make check and make check-kmod' tests and everything was fine so the patches don't seem break anything. I'm still concerned though that the test coverage probably didn't hit any parts of your code. I'm wondering if there is some way I can test the code path and get some test coverage there. Could you write up a self test for the tests/system-traffic.at kernel test? Of if that's not practical is there some other way I could test this code? > > Thanks, > > - Greg > > _______________________________________________ > dev mailing list > dev@openvswitch.org > https://mail.openvswitch.org/mailman/listinfo/ovs-dev
On 1/31/2018 6:12 AM, Yang, Yi Y wrote: > Hi, Eric > > My kernel is 4.13.0-rc6, so I'm very sure it can support vxlan-gpe, I can add vxlan-gpe port without any issue by command line, so I don't know what happened. > > Greg, I checked unit tests in tests/system-traffic.at and tests/system-layer3-tunnels.at for vxlan and vxlan-gpe, I think they are very tricky, for NSH, they won't work, current test infrastructure can't handle NSH unit test in kernel data path, so I don't think I can add it. I have posted v2 patch series, I have sfc test environment in my machine and have verified kernel data path, my test environment has two vagrant VMs, each one VM starts two containers which play SF roles, end-to-end ping and http are both ok. Could you provide instructions on how to configure your setup so I can replicate? That would provide a lot of confidence. Thanks, - Greg > > -----Original Message----- > From: Eric Garver [mailto:e@erig.me] > Sent: Tuesday, January 30, 2018 9:53 PM > To: Yang, Yi Y <yi.y.yang@intel.com> > Cc: Gregory Rose <gvrose8192@gmail.com>; dev@openvswitch.org > Subject: Re: [ovs-dev] [PATCH v1 0/5] datapath: enable NSH support in kernel compat mode > > On Tue, Jan 30, 2018 at 11:33:55AM +0000, Yang, Yi Y wrote: >> Hi, Greg >> >> I installed linux 3.10.107 in Ubuntu 14.04 and fixed >> skb_gso_error_unwind issue, but for unit test, >> tests/system-layer3-tunnels.at is a good reference for it because we >> used vxlan-gpe for nsh, I ran unit test 90, but it always fails (I >> have installed and used net-next kernel and the latest iproute2) >> >> Here is error log >> >> ./system-layer3-tunnels.at:25: ip netns exec at_ns0 sh << >> NS_EXEC_HEREDOC ip route add 10.1.1.2/32 encap ip id 0 dst >> 172.31.1.100 dev at_vxlan1 NS_EXEC_HEREDOC >> --- /dev/null 2018-01-30 02:18:43.272647961 +0000 >> +++ /home/vagrant/ovs-nsh-test/tests/system-kmod-testsuite.dir/at-groups/90/stderr 2018-01-30 09:45:15.415934534 +0000 >> @@ -0,0 +1 @@ >> +RTNETLINK answers: Operation not supported >> ./system-layer3-tunnels.at:25: exit code was 2, expected 0 >> >> I think my system missed something so “ip route add 10.1.1.2/32 encap >> ip id 0 dst 172.31.1.100 dev at_vxlan1 “ failed, Eric, what linux distribution do you know I can run “ping over VXLAN-GPE” successfully, I’ll use it as baseline to add NSH unit test for kernel data path. > When I added the tests it was on RHEL-7.4 with a net-next kernel. It should skip the tests if the installed iproute2 does not have the options for GPE. > > The error you're seeing likely means your kernel does not have GPE support. VXLAN-GPE first appeared in kernel 4.7. > > e1e5314de08b ("vxlan: implement GPE") > > As such, I think the VXLAN-GPE test case should pass on any distro with a 4.7+ kernel. > >> From: Gregory Rose [mailto:gvrose8192@gmail.com] >> Sent: Tuesday, January 30, 2018 1:51 AM >> To: Yang, Yi Y <yi.y.yang@intel.com>; dev@openvswitch.org >> Cc: blp@ovn.org; jan.scheurich@ericsson.com >> Subject: Re: [PATCH v1 0/5] datapath: enable NSH support in kernel >> compat mode >> >> On 1/10/2018 11:53 PM, Yi Yang wrote: >> >> >> This patch series is to backport NSH support patches in Linux net-next >> tree >> >> to OVS in order that it can support NSH in kernel compat mode. >> >> >> >> Yi Yang (5): >> >> datapath: ether: add NSH ethertype >> >> datapath: vxlan: factor out VXLAN-GPE next protocol >> >> datapath: net: add NSH header structures and helpers >> >> datapath: nsh: add GSO support >> >> datapath: enable NSH support >> >> >> >> NEWS | 1 + >> >> datapath/Modules.mk | 4 +- >> >> datapath/actions.c | 116 ++++++++ >> >> datapath/datapath.c | 4 + >> >> datapath/flow.c | 51 ++++ >> >> datapath/flow.h | 7 + >> >> datapath/flow_netlink.c | 343 +++++++++++++++++++++- >> >> datapath/flow_netlink.h | 5 + >> >> datapath/linux/Modules.mk | 2 + >> >> datapath/linux/compat/include/linux/if_ether.h | 4 + >> >> datapath/linux/compat/include/linux/openvswitch.h | 6 +- >> >> datapath/linux/compat/include/net/nsh.h | 313 ++++++++++++++++++++ >> >> datapath/linux/compat/include/net/tun_proto.h | 49 ++++ >> >> datapath/linux/compat/include/net/vxlan.h | 6 - >> >> datapath/linux/compat/vxlan.c | 32 +- >> >> datapath/nsh.c | 142 +++++++++ >> >> 16 files changed, 1048 insertions(+), 37 deletions(-) >> >> create mode 100644 datapath/linux/compat/include/net/nsh.h >> >> create mode 100644 datapath/linux/compat/include/net/tun_proto.h >> >> create mode 100644 datapath/nsh.c >> >> >> >> Hi Yi, >> >> My apologies for the delay in reviewing this series. >> >> I've finished up my review and I think it mostly looks pretty good but I did find an issue compiling on a 3.10.107 kernel build: >> CC [M] >> /home/travis/build/gvrose8192/ovs-experimental/datapath/linux/vport-ne >> tdev.o >> /home/travis/build/gvrose8192/ovs-experimental/datapath/linux/nsh.c:108:17: error: undefined identifier 'skb_gso_error_unwind' >> CC [M] >> /home/travis/build/gvrose8192/ovs-experimental/datapath/linux/nsh.o >> /home/travis/build/gvrose8192/ovs-experimental/datapath/linux/nsh.c: In function ‘nsh_gso_segment’: >> /home/travis/build/gvrose8192/ovs-experimental/datapath/linux/nsh.c:10 >> 8:3: error: implicit declaration of function ‘skb_gso_error_unwind’ >> [-Werror=implicit-function-declaration] >> skb_gso_error_unwind(skb, htons(ETH_P_NSH), nsh_len, ^ >> cc1: some warnings being treated as errors >> make[3]: *** >> [/home/travis/build/gvrose8192/ovs-experimental/datapath/linux/nsh.o] >> Error 1 >> make[3]: *** Waiting for unfinished jobs.... >> make[2]: *** >> [_module_/home/travis/build/gvrose8192/ovs-experimental/datapath/linux >> ] Error 2 >> make[2]: Leaving directory `/home/travis/build/gvrose8192/ovs-experimental/linux-3.10.107' >> make[1]: *** [default] Error 2 >> make[1]: Leaving directory `/home/travis/build/gvrose8192/ovs-experimental/datapath/linux' >> make: *** [all-recursive] Error 1 >> >> So we'll need to fix that up and I also think the patches will need to be rebased to current master. That second part is my fault... so sorry again about that. >> >> One other thing, I ran this through our standard 'make check and make check-kmod' tests and everything was fine so the patches don't seem break anything. I'm still concerned though that the test coverage probably didn't hit any parts of your code. I'm wondering if there is some way I can test the code path and get some test coverage there. Could you write up a self test for the tests/system-traffic.at kernel test? Of if that's not practical is there some other way I could test this code? >> >> Thanks, >> >> - Greg >> >> _______________________________________________ >> dev mailing list >> dev@openvswitch.org >> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
On Wed, Jan 31, 2018 at 02:12:14PM +0000, Yang, Yi Y wrote: > Hi, Eric > > My kernel is 4.13.0-rc6, so I'm very sure it can support vxlan-gpe, I > can add vxlan-gpe port without any issue by command line, so I don't > know what happened. Your output below indicates this is failing on this line: 25 NS_CHECK_EXEC([at_ns0], [ip route add 10.1.1.2/32 encap ip id 0 dst 172.31.1.100 dev at_vxlan1]) It does not appear to be an OVS issue. Maybe encap id 0 is not accepted on older kernels. Try changing it to a non-zero value. > > Greg, I checked unit tests in tests/system-traffic.at and tests/system-layer3-tunnels.at for vxlan and vxlan-gpe, I think they are very tricky, for NSH, they won't work, current test infrastructure can't handle NSH unit test in kernel data path, so I don't think I can add it. I have posted v2 patch series, I have sfc test environment in my machine and have verified kernel data path, my test environment has two vagrant VMs, each one VM starts two containers which play SF roles, end-to-end ping and http are both ok. > > -----Original Message----- > From: Eric Garver [mailto:e@erig.me] > Sent: Tuesday, January 30, 2018 9:53 PM > To: Yang, Yi Y <yi.y.yang@intel.com> > Cc: Gregory Rose <gvrose8192@gmail.com>; dev@openvswitch.org > Subject: Re: [ovs-dev] [PATCH v1 0/5] datapath: enable NSH support in kernel compat mode > > On Tue, Jan 30, 2018 at 11:33:55AM +0000, Yang, Yi Y wrote: > > Hi, Greg > > > > I installed linux 3.10.107 in Ubuntu 14.04 and fixed > > skb_gso_error_unwind issue, but for unit test, > > tests/system-layer3-tunnels.at is a good reference for it because we > > used vxlan-gpe for nsh, I ran unit test 90, but it always fails (I > > have installed and used net-next kernel and the latest iproute2) > > > > Here is error log > > > > ./system-layer3-tunnels.at:25: ip netns exec at_ns0 sh << > > NS_EXEC_HEREDOC ip route add 10.1.1.2/32 encap ip id 0 dst > > 172.31.1.100 dev at_vxlan1 NS_EXEC_HEREDOC > > --- /dev/null 2018-01-30 02:18:43.272647961 +0000 > > +++ /home/vagrant/ovs-nsh-test/tests/system-kmod-testsuite.dir/at-groups/90/stderr 2018-01-30 09:45:15.415934534 +0000 > > @@ -0,0 +1 @@ > > +RTNETLINK answers: Operation not supported > > ./system-layer3-tunnels.at:25: exit code was 2, expected 0 > > > > I think my system missed something so “ip route add 10.1.1.2/32 encap > > ip id 0 dst 172.31.1.100 dev at_vxlan1 “ failed, Eric, what linux distribution do you know I can run “ping over VXLAN-GPE” successfully, I’ll use it as baseline to add NSH unit test for kernel data path. > > When I added the tests it was on RHEL-7.4 with a net-next kernel. It should skip the tests if the installed iproute2 does not have the options for GPE. > > The error you're seeing likely means your kernel does not have GPE support. VXLAN-GPE first appeared in kernel 4.7. > > e1e5314de08b ("vxlan: implement GPE") > > As such, I think the VXLAN-GPE test case should pass on any distro with a 4.7+ kernel. > > > > > From: Gregory Rose [mailto:gvrose8192@gmail.com] > > Sent: Tuesday, January 30, 2018 1:51 AM > > To: Yang, Yi Y <yi.y.yang@intel.com>; dev@openvswitch.org > > Cc: blp@ovn.org; jan.scheurich@ericsson.com > > Subject: Re: [PATCH v1 0/5] datapath: enable NSH support in kernel > > compat mode > > > > On 1/10/2018 11:53 PM, Yi Yang wrote: > > > > > > This patch series is to backport NSH support patches in Linux net-next > > tree > > > > to OVS in order that it can support NSH in kernel compat mode. > > > > > > > > Yi Yang (5): > > > > datapath: ether: add NSH ethertype > > > > datapath: vxlan: factor out VXLAN-GPE next protocol > > > > datapath: net: add NSH header structures and helpers > > > > datapath: nsh: add GSO support > > > > datapath: enable NSH support > > > > > > > > NEWS | 1 + > > > > datapath/Modules.mk | 4 +- > > > > datapath/actions.c | 116 ++++++++ > > > > datapath/datapath.c | 4 + > > > > datapath/flow.c | 51 ++++ > > > > datapath/flow.h | 7 + > > > > datapath/flow_netlink.c | 343 +++++++++++++++++++++- > > > > datapath/flow_netlink.h | 5 + > > > > datapath/linux/Modules.mk | 2 + > > > > datapath/linux/compat/include/linux/if_ether.h | 4 + > > > > datapath/linux/compat/include/linux/openvswitch.h | 6 +- > > > > datapath/linux/compat/include/net/nsh.h | 313 ++++++++++++++++++++ > > > > datapath/linux/compat/include/net/tun_proto.h | 49 ++++ > > > > datapath/linux/compat/include/net/vxlan.h | 6 - > > > > datapath/linux/compat/vxlan.c | 32 +- > > > > datapath/nsh.c | 142 +++++++++ > > > > 16 files changed, 1048 insertions(+), 37 deletions(-) > > > > create mode 100644 datapath/linux/compat/include/net/nsh.h > > > > create mode 100644 datapath/linux/compat/include/net/tun_proto.h > > > > create mode 100644 datapath/nsh.c > > > > > > > > Hi Yi, > > > > My apologies for the delay in reviewing this series. > > > > I've finished up my review and I think it mostly looks pretty good but I did find an issue compiling on a 3.10.107 kernel build: > > CC [M] > > /home/travis/build/gvrose8192/ovs-experimental/datapath/linux/vport-ne > > tdev.o > > /home/travis/build/gvrose8192/ovs-experimental/datapath/linux/nsh.c:108:17: error: undefined identifier 'skb_gso_error_unwind' > > CC [M] > > /home/travis/build/gvrose8192/ovs-experimental/datapath/linux/nsh.o > > /home/travis/build/gvrose8192/ovs-experimental/datapath/linux/nsh.c: In function ‘nsh_gso_segment’: > > /home/travis/build/gvrose8192/ovs-experimental/datapath/linux/nsh.c:10 > > 8:3: error: implicit declaration of function ‘skb_gso_error_unwind’ > > [-Werror=implicit-function-declaration] > > skb_gso_error_unwind(skb, htons(ETH_P_NSH), nsh_len, ^ > > cc1: some warnings being treated as errors > > make[3]: *** > > [/home/travis/build/gvrose8192/ovs-experimental/datapath/linux/nsh.o] > > Error 1 > > make[3]: *** Waiting for unfinished jobs.... > > make[2]: *** > > [_module_/home/travis/build/gvrose8192/ovs-experimental/datapath/linux > > ] Error 2 > > make[2]: Leaving directory `/home/travis/build/gvrose8192/ovs-experimental/linux-3.10.107' > > make[1]: *** [default] Error 2 > > make[1]: Leaving directory `/home/travis/build/gvrose8192/ovs-experimental/datapath/linux' > > make: *** [all-recursive] Error 1 > > > > So we'll need to fix that up and I also think the patches will need to be rebased to current master. That second part is my fault... so sorry again about that. > > > > One other thing, I ran this through our standard 'make check and make check-kmod' tests and everything was fine so the patches don't seem break anything. I'm still concerned though that the test coverage probably didn't hit any parts of your code. I'm wondering if there is some way I can test the code path and get some test coverage there. Could you write up a self test for the tests/system-traffic.at kernel test? Of if that's not practical is there some other way I could test this code? > > > > Thanks, > > > > - Greg > > > > _______________________________________________ > > dev mailing list > > dev@openvswitch.org > > https://mail.openvswitch.org/mailman/listinfo/ovs-dev > _______________________________________________ > dev mailing list > dev@openvswitch.org > https://mail.openvswitch.org/mailman/listinfo/ovs-dev
It still failed. Does "encap ip" require any special kernel module? vagrant@gbpsfc4:~/ovs-nsh-test$ export PATH=/home/vagrant/iproute2-4.9.0/ip:$PATH vagrant@gbpsfc4:~/ovs-nsh-test$ sudo -E ip link add dev at_vxlan1 type vxlan dstport 4790 external gpe vagrant@gbpsfc4:~/ovs-nsh-test$ sudo -E ip addr add dev at_vxlan1 10.1.1.1/24 vagrant@gbpsfc4:~/ovs-nsh-test$ sudo -E ip link set dev at_vxlan1 mtu 1450 up vagrant@gbpsfc4:~/ovs-nsh-test$ sudo -E ip route add 10.1.1.2/32 encap ip id 0 dst 172.31.1.100 dev at_vxlan1 RTNETLINK answers: Operation not supported vagrant@gbpsfc4:~/ovs-nsh-test$ sudo -E ip route add 10.1.1.2/32 encap ip id 1 dst 172.31.1.100 dev at_vxlan1 RTNETLINK answers: Operation not supported vagrant@gbpsfc4:~/ovs-nsh-test$ sudo -E ip route add 10.1.1.2/32 encap ip dst 172.31.1.100 dev at_vxlan1 RTNETLINK answers: Operation not supported vagrant@gbpsfc4:~/ovs-nsh-test$ lsmod Module Size Used by vxlan 53248 0 ip6_udp_tunnel 16384 1 vxlan udp_tunnel 16384 1 vxlan ip6_tunnel 32768 0 tunnel6 16384 1 ip6_tunnel ipip 16384 0 tunnel4 16384 1 ipip ip_tunnel 24576 1 ipip veth 16384 0 nf_conntrack_ipv6 20480 0 nf_defrag_ipv6 36864 1 nf_conntrack_ipv6 xt_addrtype 16384 2 xt_conntrack 16384 1 ipt_MASQUERADE 16384 1 nf_nat_masquerade_ipv4 16384 1 ipt_MASQUERADE iptable_nat 16384 1 dm_crypt 36864 0 nf_conntrack_ipv4 16384 3 nf_defrag_ipv4 16384 1 nf_conntrack_ipv4 nf_nat_ipv4 16384 1 iptable_nat nf_nat 28672 2 nf_nat_masquerade_ipv4,nf_nat_ipv4 nf_conntrack 131072 7 nf_conntrack_ipv6,nf_conntrack_ipv4,ipt_MASQUERADE,nf_nat_masquerade_ipv4,xt_conntrack,nf_nat_ipv4,nf_nat bridge 143360 0 stp 16384 1 bridge llc 16384 2 bridge,stp dm_thin_pool 65536 1 dm_persistent_data 69632 1 dm_thin_pool dm_bio_prison 20480 1 dm_thin_pool dm_bufio 28672 1 dm_persistent_data libcrc32c 16384 3 nf_conntrack,dm_persistent_data,nf_nat nfsd 299008 2 iptable_filter 16384 1 ip_tables 24576 2 iptable_filter,iptable_nat x_tables 36864 5 ip_tables,iptable_filter,ipt_MASQUERADE,xt_addrtype,xt_conntrack auth_rpcgss 57344 1 nfsd nfs_acl 16384 1 nfsd nfs 241664 0 lockd 90112 2 nfsd,nfs grace 16384 2 nfsd,lockd sunrpc 327680 6 auth_rpcgss,nfsd,nfs_acl,lockd,nfs fscache 65536 1 nfs psmouse 139264 0 e1000 139264 0 ppdev 20480 0 parport_pc 32768 0 i2c_piix4 24576 0 mac_hid 16384 0 sb_edac 24576 0 serio_raw 16384 0 lp 20480 0 parport 49152 3 lp,parport_pc,ppdev pata_acpi 16384 0 video 40960 0 vagrant@gbpsfc4:~/ovs-nsh-test$ -----Original Message----- From: Eric Garver [mailto:e@erig.me] Sent: Thursday, February 1, 2018 5:10 AM To: Yang, Yi Y <yi.y.yang@intel.com> Cc: dev@openvswitch.org Subject: Re: [ovs-dev] [PATCH v1 0/5] datapath: enable NSH support in kernel compat mode On Wed, Jan 31, 2018 at 02:12:14PM +0000, Yang, Yi Y wrote: > Hi, Eric > > My kernel is 4.13.0-rc6, so I'm very sure it can support vxlan-gpe, I > can add vxlan-gpe port without any issue by command line, so I don't > know what happened. Your output below indicates this is failing on this line: 25 NS_CHECK_EXEC([at_ns0], [ip route add 10.1.1.2/32 encap ip id 0 dst 172.31.1.100 dev at_vxlan1]) It does not appear to be an OVS issue. Maybe encap id 0 is not accepted on older kernels. Try changing it to a non-zero value. > > Greg, I checked unit tests in tests/system-traffic.at and tests/system-layer3-tunnels.at for vxlan and vxlan-gpe, I think they are very tricky, for NSH, they won't work, current test infrastructure can't handle NSH unit test in kernel data path, so I don't think I can add it. I have posted v2 patch series, I have sfc test environment in my machine and have verified kernel data path, my test environment has two vagrant VMs, each one VM starts two containers which play SF roles, end-to-end ping and http are both ok. > > -----Original Message----- > From: Eric Garver [mailto:e@erig.me] > Sent: Tuesday, January 30, 2018 9:53 PM > To: Yang, Yi Y <yi.y.yang@intel.com> > Cc: Gregory Rose <gvrose8192@gmail.com>; dev@openvswitch.org > Subject: Re: [ovs-dev] [PATCH v1 0/5] datapath: enable NSH support in > kernel compat mode > > On Tue, Jan 30, 2018 at 11:33:55AM +0000, Yang, Yi Y wrote: > > Hi, Greg > > > > I installed linux 3.10.107 in Ubuntu 14.04 and fixed > > skb_gso_error_unwind issue, but for unit test, > > tests/system-layer3-tunnels.at is a good reference for it because we > > used vxlan-gpe for nsh, I ran unit test 90, but it always fails (I > > have installed and used net-next kernel and the latest iproute2) > > > > Here is error log > > > > ./system-layer3-tunnels.at:25: ip netns exec at_ns0 sh << > > NS_EXEC_HEREDOC ip route add 10.1.1.2/32 encap ip id 0 dst > > 172.31.1.100 dev at_vxlan1 NS_EXEC_HEREDOC > > --- /dev/null 2018-01-30 02:18:43.272647961 +0000 > > +++ /home/vagrant/ovs-nsh-test/tests/system-kmod-testsuite.dir/at-groups/90/stderr 2018-01-30 09:45:15.415934534 +0000 > > @@ -0,0 +1 @@ > > +RTNETLINK answers: Operation not supported > > ./system-layer3-tunnels.at:25: exit code was 2, expected 0 > > > > I think my system missed something so “ip route add 10.1.1.2/32 > > encap ip id 0 dst 172.31.1.100 dev at_vxlan1 “ failed, Eric, what linux distribution do you know I can run “ping over VXLAN-GPE” successfully, I’ll use it as baseline to add NSH unit test for kernel data path. > > When I added the tests it was on RHEL-7.4 with a net-next kernel. It should skip the tests if the installed iproute2 does not have the options for GPE. > > The error you're seeing likely means your kernel does not have GPE support. VXLAN-GPE first appeared in kernel 4.7. > > e1e5314de08b ("vxlan: implement GPE") > > As such, I think the VXLAN-GPE test case should pass on any distro with a 4.7+ kernel. > > > > > From: Gregory Rose [mailto:gvrose8192@gmail.com] > > Sent: Tuesday, January 30, 2018 1:51 AM > > To: Yang, Yi Y <yi.y.yang@intel.com>; dev@openvswitch.org > > Cc: blp@ovn.org; jan.scheurich@ericsson.com > > Subject: Re: [PATCH v1 0/5] datapath: enable NSH support in kernel > > compat mode > > > > On 1/10/2018 11:53 PM, Yi Yang wrote: > > > > > > This patch series is to backport NSH support patches in Linux > > net-next tree > > > > to OVS in order that it can support NSH in kernel compat mode. > > > > > > > > Yi Yang (5): > > > > datapath: ether: add NSH ethertype > > > > datapath: vxlan: factor out VXLAN-GPE next protocol > > > > datapath: net: add NSH header structures and helpers > > > > datapath: nsh: add GSO support > > > > datapath: enable NSH support > > > > > > > > NEWS | 1 + > > > > datapath/Modules.mk | 4 +- > > > > datapath/actions.c | 116 ++++++++ > > > > datapath/datapath.c | 4 + > > > > datapath/flow.c | 51 ++++ > > > > datapath/flow.h | 7 + > > > > datapath/flow_netlink.c | 343 +++++++++++++++++++++- > > > > datapath/flow_netlink.h | 5 + > > > > datapath/linux/Modules.mk | 2 + > > > > datapath/linux/compat/include/linux/if_ether.h | 4 + > > > > datapath/linux/compat/include/linux/openvswitch.h | 6 +- > > > > datapath/linux/compat/include/net/nsh.h | 313 ++++++++++++++++++++ > > > > datapath/linux/compat/include/net/tun_proto.h | 49 ++++ > > > > datapath/linux/compat/include/net/vxlan.h | 6 - > > > > datapath/linux/compat/vxlan.c | 32 +- > > > > datapath/nsh.c | 142 +++++++++ > > > > 16 files changed, 1048 insertions(+), 37 deletions(-) > > > > create mode 100644 datapath/linux/compat/include/net/nsh.h > > > > create mode 100644 datapath/linux/compat/include/net/tun_proto.h > > > > create mode 100644 datapath/nsh.c > > > > > > > > Hi Yi, > > > > My apologies for the delay in reviewing this series. > > > > I've finished up my review and I think it mostly looks pretty good but I did find an issue compiling on a 3.10.107 kernel build: > > CC [M] > > /home/travis/build/gvrose8192/ovs-experimental/datapath/linux/vport- > > ne > > tdev.o > > /home/travis/build/gvrose8192/ovs-experimental/datapath/linux/nsh.c:108:17: error: undefined identifier 'skb_gso_error_unwind' > > CC [M] > > /home/travis/build/gvrose8192/ovs-experimental/datapath/linux/nsh.o > > /home/travis/build/gvrose8192/ovs-experimental/datapath/linux/nsh.c: In function ‘nsh_gso_segment’: > > /home/travis/build/gvrose8192/ovs-experimental/datapath/linux/nsh.c: > > 10 > > 8:3: error: implicit declaration of function ‘skb_gso_error_unwind’ > > [-Werror=implicit-function-declaration] > > skb_gso_error_unwind(skb, htons(ETH_P_NSH), nsh_len, ^ > > cc1: some warnings being treated as errors > > make[3]: *** > > [/home/travis/build/gvrose8192/ovs-experimental/datapath/linux/nsh.o > > ] > > Error 1 > > make[3]: *** Waiting for unfinished jobs.... > > make[2]: *** > > [_module_/home/travis/build/gvrose8192/ovs-experimental/datapath/lin > > ux > > ] Error 2 > > make[2]: Leaving directory `/home/travis/build/gvrose8192/ovs-experimental/linux-3.10.107' > > make[1]: *** [default] Error 2 > > make[1]: Leaving directory `/home/travis/build/gvrose8192/ovs-experimental/datapath/linux' > > make: *** [all-recursive] Error 1 > > > > So we'll need to fix that up and I also think the patches will need to be rebased to current master. That second part is my fault... so sorry again about that. > > > > One other thing, I ran this through our standard 'make check and make check-kmod' tests and everything was fine so the patches don't seem break anything. I'm still concerned though that the test coverage probably didn't hit any parts of your code. I'm wondering if there is some way I can test the code path and get some test coverage there. Could you write up a self test for the tests/system-traffic.at kernel test? Of if that's not practical is there some other way I could test this code? > > > > Thanks, > > > > - Greg > > > > _______________________________________________ > > dev mailing list > > dev@openvswitch.org > > https://mail.openvswitch.org/mailman/listinfo/ovs-dev > _______________________________________________ > dev mailing list > dev@openvswitch.org > https://mail.openvswitch.org/mailman/listinfo/ovs-dev
On Thu, Feb 01, 2018 at 02:25:37AM +0000, Yang, Yi Y wrote: > It still failed. Does "encap ip" require any special kernel module? CONFIG_LWTUNNEL, but that should already be enabled for OVS. I was unable to reproduce on RHEL-7.4 with a v4.13 kernel and iproute 4.11.0 (I also tried 4.9.0). # uname -a Linux dev-rhel7 4.13.0 #40 SMP Thu Feb 1 10:28:06 EST 2018 x86_64 x86_64 x86_64 GNU/Linux # yum info iproute Version : 4.11.0 Release : 13.el7 > > vagrant@gbpsfc4:~/ovs-nsh-test$ export PATH=/home/vagrant/iproute2-4.9.0/ip:$PATH > vagrant@gbpsfc4:~/ovs-nsh-test$ sudo -E ip link add dev at_vxlan1 type vxlan dstport 4790 external gpe > vagrant@gbpsfc4:~/ovs-nsh-test$ sudo -E ip addr add dev at_vxlan1 10.1.1.1/24 > vagrant@gbpsfc4:~/ovs-nsh-test$ sudo -E ip link set dev at_vxlan1 mtu 1450 up > vagrant@gbpsfc4:~/ovs-nsh-test$ sudo -E ip route add 10.1.1.2/32 encap ip id 0 dst 172.31.1.100 dev at_vxlan1 > RTNETLINK answers: Operation not supported > vagrant@gbpsfc4:~/ovs-nsh-test$ sudo -E ip route add 10.1.1.2/32 encap ip id 1 dst 172.31.1.100 dev at_vxlan1 > RTNETLINK answers: Operation not supported > vagrant@gbpsfc4:~/ovs-nsh-test$ sudo -E ip route add 10.1.1.2/32 encap ip dst 172.31.1.100 dev at_vxlan1 > RTNETLINK answers: Operation not supported > vagrant@gbpsfc4:~/ovs-nsh-test$ lsmod > Module Size Used by > vxlan 53248 0 > ip6_udp_tunnel 16384 1 vxlan > udp_tunnel 16384 1 vxlan > ip6_tunnel 32768 0 > tunnel6 16384 1 ip6_tunnel > ipip 16384 0 > tunnel4 16384 1 ipip > ip_tunnel 24576 1 ipip > veth 16384 0 > nf_conntrack_ipv6 20480 0 > nf_defrag_ipv6 36864 1 nf_conntrack_ipv6 > xt_addrtype 16384 2 > xt_conntrack 16384 1 > ipt_MASQUERADE 16384 1 > nf_nat_masquerade_ipv4 16384 1 ipt_MASQUERADE > iptable_nat 16384 1 > dm_crypt 36864 0 > nf_conntrack_ipv4 16384 3 > nf_defrag_ipv4 16384 1 nf_conntrack_ipv4 > nf_nat_ipv4 16384 1 iptable_nat > nf_nat 28672 2 nf_nat_masquerade_ipv4,nf_nat_ipv4 > nf_conntrack 131072 7 nf_conntrack_ipv6,nf_conntrack_ipv4,ipt_MASQUERADE,nf_nat_masquerade_ipv4,xt_conntrack,nf_nat_ipv4,nf_nat > bridge 143360 0 > stp 16384 1 bridge > llc 16384 2 bridge,stp > dm_thin_pool 65536 1 > dm_persistent_data 69632 1 dm_thin_pool > dm_bio_prison 20480 1 dm_thin_pool > dm_bufio 28672 1 dm_persistent_data > libcrc32c 16384 3 nf_conntrack,dm_persistent_data,nf_nat > nfsd 299008 2 > iptable_filter 16384 1 > ip_tables 24576 2 iptable_filter,iptable_nat > x_tables 36864 5 ip_tables,iptable_filter,ipt_MASQUERADE,xt_addrtype,xt_conntrack > auth_rpcgss 57344 1 nfsd > nfs_acl 16384 1 nfsd > nfs 241664 0 > lockd 90112 2 nfsd,nfs > grace 16384 2 nfsd,lockd > sunrpc 327680 6 auth_rpcgss,nfsd,nfs_acl,lockd,nfs > fscache 65536 1 nfs > psmouse 139264 0 > e1000 139264 0 > ppdev 20480 0 > parport_pc 32768 0 > i2c_piix4 24576 0 > mac_hid 16384 0 > sb_edac 24576 0 > serio_raw 16384 0 > lp 20480 0 > parport 49152 3 lp,parport_pc,ppdev > pata_acpi 16384 0 > video 40960 0 > vagrant@gbpsfc4:~/ovs-nsh-test$ > -----Original Message----- > From: Eric Garver [mailto:e@erig.me] > Sent: Thursday, February 1, 2018 5:10 AM > To: Yang, Yi Y <yi.y.yang@intel.com> > Cc: dev@openvswitch.org > Subject: Re: [ovs-dev] [PATCH v1 0/5] datapath: enable NSH support in kernel compat mode > > On Wed, Jan 31, 2018 at 02:12:14PM +0000, Yang, Yi Y wrote: > > Hi, Eric > > > > My kernel is 4.13.0-rc6, so I'm very sure it can support vxlan-gpe, I > > can add vxlan-gpe port without any issue by command line, so I don't > > know what happened. > > Your output below indicates this is failing on this line: > > 25 NS_CHECK_EXEC([at_ns0], [ip route add 10.1.1.2/32 encap ip id 0 dst 172.31.1.100 dev at_vxlan1]) > > It does not appear to be an OVS issue. Maybe encap id 0 is not accepted on older kernels. Try changing it to a non-zero value. > > > > > Greg, I checked unit tests in tests/system-traffic.at and tests/system-layer3-tunnels.at for vxlan and vxlan-gpe, I think they are very tricky, for NSH, they won't work, current test infrastructure can't handle NSH unit test in kernel data path, so I don't think I can add it. I have posted v2 patch series, I have sfc test environment in my machine and have verified kernel data path, my test environment has two vagrant VMs, each one VM starts two containers which play SF roles, end-to-end ping and http are both ok. > > > > -----Original Message----- > > From: Eric Garver [mailto:e@erig.me] > > Sent: Tuesday, January 30, 2018 9:53 PM > > To: Yang, Yi Y <yi.y.yang@intel.com> > > Cc: Gregory Rose <gvrose8192@gmail.com>; dev@openvswitch.org > > Subject: Re: [ovs-dev] [PATCH v1 0/5] datapath: enable NSH support in > > kernel compat mode > > > > On Tue, Jan 30, 2018 at 11:33:55AM +0000, Yang, Yi Y wrote: > > > Hi, Greg > > > > > > I installed linux 3.10.107 in Ubuntu 14.04 and fixed > > > skb_gso_error_unwind issue, but for unit test, > > > tests/system-layer3-tunnels.at is a good reference for it because we > > > used vxlan-gpe for nsh, I ran unit test 90, but it always fails (I > > > have installed and used net-next kernel and the latest iproute2) > > > > > > Here is error log > > > > > > ./system-layer3-tunnels.at:25: ip netns exec at_ns0 sh << > > > NS_EXEC_HEREDOC ip route add 10.1.1.2/32 encap ip id 0 dst > > > 172.31.1.100 dev at_vxlan1 NS_EXEC_HEREDOC > > > --- /dev/null 2018-01-30 02:18:43.272647961 +0000 > > > +++ /home/vagrant/ovs-nsh-test/tests/system-kmod-testsuite.dir/at-groups/90/stderr 2018-01-30 09:45:15.415934534 +0000 > > > @@ -0,0 +1 @@ > > > +RTNETLINK answers: Operation not supported > > > ./system-layer3-tunnels.at:25: exit code was 2, expected 0 > > > > > > I think my system missed something so “ip route add 10.1.1.2/32 > > > encap ip id 0 dst 172.31.1.100 dev at_vxlan1 “ failed, Eric, what linux distribution do you know I can run “ping over VXLAN-GPE” successfully, I’ll use it as baseline to add NSH unit test for kernel data path. > > > > When I added the tests it was on RHEL-7.4 with a net-next kernel. It should skip the tests if the installed iproute2 does not have the options for GPE. > > > > The error you're seeing likely means your kernel does not have GPE support. VXLAN-GPE first appeared in kernel 4.7. > > > > e1e5314de08b ("vxlan: implement GPE") > > > > As such, I think the VXLAN-GPE test case should pass on any distro with a 4.7+ kernel. > > > > > > > > From: Gregory Rose [mailto:gvrose8192@gmail.com] > > > Sent: Tuesday, January 30, 2018 1:51 AM > > > To: Yang, Yi Y <yi.y.yang@intel.com>; dev@openvswitch.org > > > Cc: blp@ovn.org; jan.scheurich@ericsson.com > > > Subject: Re: [PATCH v1 0/5] datapath: enable NSH support in kernel > > > compat mode > > > > > > On 1/10/2018 11:53 PM, Yi Yang wrote: > > > > > > > > > This patch series is to backport NSH support patches in Linux > > > net-next tree > > > > > > to OVS in order that it can support NSH in kernel compat mode. > > > > > > > > > > > > Yi Yang (5): > > > > > > datapath: ether: add NSH ethertype > > > > > > datapath: vxlan: factor out VXLAN-GPE next protocol > > > > > > datapath: net: add NSH header structures and helpers > > > > > > datapath: nsh: add GSO support > > > > > > datapath: enable NSH support > > > > > > > > > > > > NEWS | 1 + > > > > > > datapath/Modules.mk | 4 +- > > > > > > datapath/actions.c | 116 ++++++++ > > > > > > datapath/datapath.c | 4 + > > > > > > datapath/flow.c | 51 ++++ > > > > > > datapath/flow.h | 7 + > > > > > > datapath/flow_netlink.c | 343 +++++++++++++++++++++- > > > > > > datapath/flow_netlink.h | 5 + > > > > > > datapath/linux/Modules.mk | 2 + > > > > > > datapath/linux/compat/include/linux/if_ether.h | 4 + > > > > > > datapath/linux/compat/include/linux/openvswitch.h | 6 +- > > > > > > datapath/linux/compat/include/net/nsh.h | 313 ++++++++++++++++++++ > > > > > > datapath/linux/compat/include/net/tun_proto.h | 49 ++++ > > > > > > datapath/linux/compat/include/net/vxlan.h | 6 - > > > > > > datapath/linux/compat/vxlan.c | 32 +- > > > > > > datapath/nsh.c | 142 +++++++++ > > > > > > 16 files changed, 1048 insertions(+), 37 deletions(-) > > > > > > create mode 100644 datapath/linux/compat/include/net/nsh.h > > > > > > create mode 100644 datapath/linux/compat/include/net/tun_proto.h > > > > > > create mode 100644 datapath/nsh.c > > > > > > > > > > > > Hi Yi, > > > > > > My apologies for the delay in reviewing this series. > > > > > > I've finished up my review and I think it mostly looks pretty good but I did find an issue compiling on a 3.10.107 kernel build: > > > CC [M] > > > /home/travis/build/gvrose8192/ovs-experimental/datapath/linux/vport- > > > ne > > > tdev.o > > > /home/travis/build/gvrose8192/ovs-experimental/datapath/linux/nsh.c:108:17: error: undefined identifier 'skb_gso_error_unwind' > > > CC [M] > > > /home/travis/build/gvrose8192/ovs-experimental/datapath/linux/nsh.o > > > /home/travis/build/gvrose8192/ovs-experimental/datapath/linux/nsh.c: In function ‘nsh_gso_segment’: > > > /home/travis/build/gvrose8192/ovs-experimental/datapath/linux/nsh.c: > > > 10 > > > 8:3: error: implicit declaration of function ‘skb_gso_error_unwind’ > > > [-Werror=implicit-function-declaration] > > > skb_gso_error_unwind(skb, htons(ETH_P_NSH), nsh_len, ^ > > > cc1: some warnings being treated as errors > > > make[3]: *** > > > [/home/travis/build/gvrose8192/ovs-experimental/datapath/linux/nsh.o > > > ] > > > Error 1 > > > make[3]: *** Waiting for unfinished jobs.... > > > make[2]: *** > > > [_module_/home/travis/build/gvrose8192/ovs-experimental/datapath/lin > > > ux > > > ] Error 2 > > > make[2]: Leaving directory `/home/travis/build/gvrose8192/ovs-experimental/linux-3.10.107' > > > make[1]: *** [default] Error 2 > > > make[1]: Leaving directory `/home/travis/build/gvrose8192/ovs-experimental/datapath/linux' > > > make: *** [all-recursive] Error 1 > > > > > > So we'll need to fix that up and I also think the patches will need to be rebased to current master. That second part is my fault... so sorry again about that. > > > > > > One other thing, I ran this through our standard 'make check and make check-kmod' tests and everything was fine so the patches don't seem break anything. I'm still concerned though that the test coverage probably didn't hit any parts of your code. I'm wondering if there is some way I can test the code path and get some test coverage there. Could you write up a self test for the tests/system-traffic.at kernel test? Of if that's not practical is there some other way I could test this code? > > > > > > Thanks, > > > > > > - Greg > > > > > > _______________________________________________ > > > dev mailing list > > > dev@openvswitch.org > > > https://mail.openvswitch.org/mailman/listinfo/ovs-dev > > _______________________________________________ > > dev mailing list > > dev@openvswitch.org > > https://mail.openvswitch.org/mailman/listinfo/ovs-dev > _______________________________________________ > dev mailing list > dev@openvswitch.org > https://mail.openvswitch.org/mailman/listinfo/ovs-dev