[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