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.y...@intel.com> > Cc: Gregory Rose <gvrose8...@gmail.com>; d...@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:gvrose8...@gmail.com] > > Sent: Tuesday, January 30, 2018 1:51 AM > > To: Yang, Yi Y <yi.y.y...@intel.com>; d...@openvswitch.org > > Cc: b...@ovn.org; jan.scheur...@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 > > 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 _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
