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:[email protected]] > Sent: Thursday, February 1, 2018 5:10 AM > To: Yang, Yi Y <[email protected]> > Cc: [email protected] > 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:[email protected]] > > Sent: Tuesday, January 30, 2018 9:53 PM > > To: Yang, Yi Y <[email protected]> > > Cc: Gregory Rose <[email protected]>; [email protected] > > 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:[email protected]] > > > Sent: Tuesday, January 30, 2018 1:51 AM > > > To: Yang, Yi Y <[email protected]>; [email protected] > > > Cc: [email protected]; [email protected] > > > 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 > > > [email protected] > > > https://mail.openvswitch.org/mailman/listinfo/ovs-dev > > _______________________________________________ > > dev mailing list > > [email protected] > > https://mail.openvswitch.org/mailman/listinfo/ovs-dev > _______________________________________________ > dev mailing list > [email protected] > https://mail.openvswitch.org/mailman/listinfo/ovs-dev _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
