[ovs-discuss] Re：[HELP] Question about userspace geneve/vxlan port

[txfh2007]

Hi Ben：
    I have read the "userspace tunnel" document for several times, but I still have no clue how could the tunnel pkt get parsed in rx direction.  In my first mail, I have found the "tnl_port_receive" should only be called during upcall process, but for userspace upcall process ,after miniflow_extract the metadata field has been set to "0", so the tunnel header can't be parsed.

   My test env is as below, there are two OVS userspace bridges, if dpdk0 on br-provider receive a pkt with tunnel header, the pkt would be delivered to internal port br-provider, but can't be sent to OVN-XXX port on br-int. 
   I am wondering if my test topology is wrong or there are other mechanism to parse tunnel hdr.

Thank you !

Timo  

    Bridge br-int
        fail_mode: secure

        Port "ovn-e1c6a3-0"
            Interface "ovn-e1c6a3-0"
                type: geneve
                options: {csum="true", key=flow, remote_ip="10.142.18.12"}
        Port "vhuf77e9f1f-d9"
            Interface "vhuf77e9f1f-d9"
                type: dpdkvhostuser

        Port br-int
            Interface br-int
                type: internal

    Bridge br-provider
        Port br-provider
            Interface br-provider
                type: internal

        Port "dpdk0"
            Interface "dpdk0"
                type: dpdk
                options: {dpdk-devargs="0000:02:00.0", n_rxq="2"}

------------------------------------------------------------------
Ben Pfaff <blp at ovn.org>
txfh2007 <txfh2007 at aliyun.com>
ovs-discuss <ovs-discuss at openvswitch.org>
Re: Re：[ovs-discuss] Re：[HELP] Question about userspace geneve/vxlan port


Native tunneling and userspace tunneling are the same thing.

The mechanism should be symmetric: configuration for sending packets out
should also work for parsing them on the way back in.

On Mon, Jul 08, 2019 at 03:57:46PM +0800, txfh2007 wrote:
> Hi Ben:
>     Thanks for your reply ! I didn't find the "native tunneling" document in OpenvSwitch repository. Did you mean the document "userspace-tunneling.rst". this document just tells us the br-phy can send tunnel pkt out, but when dpdk type port receives pkts with tunnel hdr, how could I configure the "native tunnel" mechanism to parse and handle these pkts? Or what you mean is currently OVS cannot handle parsing tunnel pkts in userspace ?
> 
>     Thank you 
> 
> Timo 
> 
> 
> ------------------------------------------------------------------
> Ben Pfaff <blp at ovn.org>
> txfh2007 <txfh2007 at aliyun.com>
> ovs-discuss <ovs-discuss at openvswitch.org>
> Re: [ovs-discuss] Re：[HELP] Question about userspace geneve/vxlan port
> 
> 
> On Thu, Jul 04, 2019 at 05:27:28PM +0800, txfh2007 via discuss wrote:
> > I have found theoritically during the upcall process, task
> > tnl_port_receive could be called(via upcall_cb() -> upcall_receive()
> > -> xlate_lookup() ->xport_lookup). But in my env, after tracing code
> > by gdb, I have found the task "tnl_port_should_receive(flow)" always
> > returns "false" for flow->tunnel->ip_dst is "0", even if the pkt
> > received by dpdk port has a tunnel header.
> 
> Yes.
> 
> > I guess the reason is in userspace task "handle_packet_upcall", the
> > match.tun_md.valid has been set "false", so the expanded flow has no
> > tunnel info, and also in task "miniflow_extract" in flow.c, the
> > packet->md is null as in dfc_processing task the "md_is_valid" flag is
> > always "false". Am I right ?
> 
> Yes.
> 
> OVS takes what some might consider an idiosyncratic approach to tunnel
> processing.  The "obvious" approach is to simply parse tunnel headers
> and throw those into the flow.  If OVS did that, then you'd see what you
> expect, but this isn't what OVS does.
> 
> Instead, OVS treats tunnel and their headers as metadata.  This is
> because of OVS's history as part of the Linux kernel.  The Linux kernel
> has tunnel implementations as part of the TCP/IP stack.  When a tunnel
> packet arrives at a physical port in Linux, it passes into the TCP/IP
> stack, where it gets processed and received on a tunnel network device.
> This effectively strips the tunnel headers and transforms them into
> metadata.  If the tunnel network device is part of an OVS bridge, then
> it gets the packet at that point, and treats the metadata as something
> that can be matched.
> 
> With other datapaths, OVS expects some equivalent mechanism to exist.
> For the userspace datapath, OVS implements "native tunneling" to provide
> that mechanism.  It's described in the OVS documentation.
>