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.y...@intel.com> Cc: d...@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.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/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 > > 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
