[ovs-dev] [PATCH v9 0/7] OVS-DPDK flow offload with rte_flow
Koujalagi, MalleshX
malleshx.koujalagi at intel.com
Tue Jun 19 22:58:49 UTC 2018
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:shahafs at mellanox.com]
Sent: Monday, June 18, 2018 4:05 AM
To: Koujalagi, MalleshX <malleshx.koujalagi at intel.com>; yliu at fridaylinux.org; fc at napatech.com
Cc: dev at openvswitch.org; Ergin, Mesut A <mesut.a.ergin at intel.com>; Tsai, James <james.tsai at 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.koujalagi at intel.com<mailto:malleshx.koujalagi at intel.com>>
Sent: Friday, June 15, 2018 9:29 PM
To: Shahaf Shuler <shahafs at mellanox.com<mailto:shahafs at mellanox.com>>; yliu at fridaylinux.org<mailto:yliu at fridaylinux.org>; fc at napatech.com<mailto:fc at napatech.com>
Cc: dev at openvswitch.org<mailto:dev at openvswitch.org>; Ergin, Mesut A <mesut.a.ergin at intel.com<mailto:mesut.a.ergin at intel.com>>; Tsai, James <james.tsai at intel.com<mailto:james.tsai at 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
More information about the dev
mailing list