Hi Shahaf, Thanks for setting up VXLAN env. and trying to reproduce, appreciate!!
As you suggested, I moved to DPDK17.11.3 stable and OvS 2.9.0, still observed same issue. An attached Vxlan_diagram.jpg, to get clear idea, we are seeing issue while traffic injected from Traffic Generator-->HOST B[eth1-->Vxlan-->eth0]-->Vxlan Tunnel Packet-->HOST A[eth0-->Vxlan-->eth1]-->Traffic Generator direction, at Host A (eth0-->Vxlan-->eth1), we see Vxlan DECAP issue in case of HW-offload enabled. Vxlan Tunnel packets are not DECAP from eth0 to eth1, not observed any packet receiving @ eth1. We injected random destination ip address(196.0.0.(0/1)), 1. Find tcpdump @ Host A (eth0). 07:24:12.013848 68:05:ca:33:ff:99 > 68:05:ca:33:fe:f9, ethertype IPv4 (0x0800), length 110: 172.168.1.2.46816 > 172.168.1.1.4789: VXLAN, flags [I] (0x08), vni 0 00:10:94:00:00:12 > 00:00:01:00:00:01, ethertype IPv4 (0x0800), length 60: 197.0.0.0.1024 > 196.0.0.1.1024: UDP, length 18 07:24:12.013860 68:05:ca:33:ff:99 > 68:05:ca:33:fe:f9, ethertype IPv4 (0x0800), length 110: 172.168.1.2.50892 > 172.168.1.1.4789: VXLAN, flags [I] (0x08), vni 0 00:10:94:00:00:12 > 00:00:01:00:00:01, ethertype IPv4 (0x0800), length 60: 197.0.0.0.1024 > 196.0.0.0.1024: UDP, length 18 2. Ovs logs. 3. Sure, further we will debug this issue using Skype/webex session. Please let me know good time. Best regards -/Mallesh From: Shahaf Shuler [mailto:shah...@mellanox.com] Sent: Monday, June 18, 2018 4:05 AM To: Koujalagi, MalleshX <malleshx.koujal...@intel.com>; y...@fridaylinux.org; f...@napatech.com Cc: d...@openvswitch.org; Ergin, Mesut A <mesut.a.er...@intel.com>; Tsai, James <james.t...@intel.com> Subject: RE: [ovs-dev] [PATCH v9 0/7] OVS-DPDK flow offload with rte_flow Mallesh, I was finally able to setup the vxlan testing w/ OVS. Instead of using OVS on both sides I used vxlan i/f to inject the traffic on one host and run ovs with vxlan tunnel configuration you specified on the other. I was not able to reproduce your case. Actually I see the rules are created successfully (see attached ovs log "vxlan_tep") Few observations: 1. The rule created for the VXLAN is for the outer pattern up to the UDP, hence supported by the device a. 2018-06-18T08:11:17.466Z|00057|dpif_netdev(pmd53)|DBG|flow match: recirc_id=0,eth,udp,vlan_tci=0x0000,dl_src=e4:1d:2d: ca:ca:6a,dl_dst=e4:1d:2d:a3:aa:74,nw_dst=2.2.2.1,nw_frag=no,tp_dst=4789 2. I do see segfault on mlx5 PMD on 17.11.0 and this was resolved on 17.11.3 stable. 3. I used MLNX_OFED_LINUX-4.3-2.0.1.0, however I don't expect it to cause any diff The packets being sent to the ovs w/ vxlan tunnel logic are[1]. tcpdump after the ovs logic is [2], the packet outer headers were removed as expected. On top of all, I tried to force the validate function to fail. Indeed the flow was not created but the decap functionality still happens (see attached ovs log "vxlan_tep_force_err") Can you please: 1. Provide me the type of packets you inject and don't see being decap. 2. Try w/ 17.11.3 stable to avoid any issues from the DPDK side 3. If you still see the issue can we set webex/skype meeting for joint debug, currently I don't see the error you reported on. [1] ###[ Ethernet ]### dst= e4:1d:2d:a3:aa:74 src= e4:1d:2d:ca:ca:6a type= IPv4 ###[ IP ]### version= 4 ihl= None tos= 0x0 len= None id= 1 flags= frag= 0 ttl= 64 proto= udp chksum= None src= 2.2.2.2 dst= 2.2.2.1 \options\ ###[ UDP ]### sport= 34550 dport= 4789 len= None chksum= None ###[ VXLAN ]### flags= I reserved1= 0 vni= 1000 reserved2= 0x0 ###[ Ethernet ]### dst= 00:00:5e:00:01:01 src= 18:66:da:f5:37:64 type= IPv4 ###[ IP ]### version= 4 ihl= None tos= 0x0 len= None id= 1 flags= frag= 0 ttl= 64 proto= tcp chksum= None src= 10.7.12.62 dst= 1.1.1.1 \options\ ###[ TCP ]### sport= ftp_data dport= http seq= 0 ack= 0 dataofs= None reserved= 0 flags= S window= 8192 chksum= None urgptr= 0 options= {} [2] 11:13:59.477667 18:66:da:f5:37:64 > 00:00:5e:00:01:01, ethertype IPv4 (0x0800), length 60: (tos 0x0, ttl 64, id 1, off set 0, flags [none], proto TCP (6), length 40) 10.7.12.62.20 > 1.1.1.1.80: Flags [S], cksum 0x7738 (correct), seq 0, win 8192, length 0 --Shahaf From: Koujalagi, MalleshX <malleshx.koujal...@intel.com<mailto:malleshx.koujal...@intel.com>> Sent: Friday, June 15, 2018 9:29 PM To: Shahaf Shuler <shah...@mellanox.com<mailto:shah...@mellanox.com>>; y...@fridaylinux.org<mailto:y...@fridaylinux.org>; f...@napatech.com<mailto:f...@napatech.com> Cc: d...@openvswitch.org<mailto:d...@openvswitch.org>; Ergin, Mesut A <mesut.a.er...@intel.com<mailto:mesut.a.er...@intel.com>>; Tsai, James <james.t...@intel.com<mailto:james.t...@intel.com>> Subject: RE: [ovs-dev] [PATCH v9 0/7] OVS-DPDK flow offload with rte_flow Hi Shahaf, Thanks for pointing NIC/protocol support. Find inline comments: >>When you say DECAP functionality is broken you mean the flow is not actually >>inserted to the HW right? [Mallesh]: Yes, DECAP flows are not inserted to HW. >>The datapath should still DECAP the flow correctly. [Mallesh]: Agree, However the datapath failed to DECAP. If VXLAN protocol support in netdev_dpdk_validate_flow failed (return -1) then, should be fall back normal or default behavior of datapath right? Have you tried w/o VXLAN tunnel rules? [Mallesh]: Yes, tried, but same behavior. Best regards, -/Mallesh
_______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev