[ovs-dev] [PATCH v9 0/7] OVS-DPDK flow offload with rte_flow
Shahaf Shuler
shahafs at mellanox.com
Mon Jun 18 11:05:13 UTC 2018
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>
Sent: Friday, June 15, 2018 9:29 PM
To: Shahaf Shuler <shahafs at mellanox.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
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