On 1/31/2018 6:12 AM, 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.

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.

Could you provide instructions on how to configure your setup so I can replicate?  That would provide a lot of
confidence.

Thanks,

- Greg


-----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/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
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Reply via email to