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 <[email protected]>
Sent: Friday, June 15, 2018 9:29 PM
To: Shahaf Shuler <[email protected]>; [email protected];
[email protected]
Cc: [email protected]; Ergin, Mesut A <[email protected]>; Tsai, James
<[email protected]>
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
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
