[ovs-dev] [PATCH v1 0/5] datapath: enable NSH support in kernel compat mode
Eric Garver
e at erig.me
Thu Feb 1 15:57:58 UTC 2018
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 at gbpsfc4:~/ovs-nsh-test$ export PATH=/home/vagrant/iproute2-4.9.0/ip:$PATH
> vagrant at gbpsfc4:~/ovs-nsh-test$ sudo -E ip link add dev at_vxlan1 type vxlan dstport 4790 external gpe
> vagrant at gbpsfc4:~/ovs-nsh-test$ sudo -E ip addr add dev at_vxlan1 10.1.1.1/24
> vagrant at gbpsfc4:~/ovs-nsh-test$ sudo -E ip link set dev at_vxlan1 mtu 1450 up
> vagrant at 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 at 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 at 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 at 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 at gbpsfc4:~/ovs-nsh-test$
> -----Original Message-----
> From: Eric Garver [mailto:e at erig.me]
> Sent: Thursday, February 1, 2018 5:10 AM
> To: Yang, Yi Y <yi.y.yang at intel.com>
> Cc: dev at 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 at erig.me]
> > Sent: Tuesday, January 30, 2018 9:53 PM
> > To: Yang, Yi Y <yi.y.yang at intel.com>
> > Cc: Gregory Rose <gvrose8192 at gmail.com>; dev at 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 at gmail.com]
> > > Sent: Tuesday, January 30, 2018 1:51 AM
> > > To: Yang, Yi Y <yi.y.yang at intel.com>; dev at openvswitch.org
> > > Cc: blp at ovn.org; jan.scheurich at 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 at openvswitch.org
> > > https://mail.openvswitch.org/mailman/listinfo/ovs-dev
> > _______________________________________________
> > dev mailing list
> > dev at openvswitch.org
> > https://mail.openvswitch.org/mailman/listinfo/ovs-dev
> _______________________________________________
> dev mailing list
> dev at openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
More information about the dev
mailing list