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-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
> 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

Reply via email to