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

txfh2007 txfh2007 at aliyun.com
Wed Jul 17 09:04:50 UTC 2019


Hi Ben & all:
    Another question about userspace tunnel: in userspace-tunnel.rst , I have found the tunnel port(vxlan port) and VM port(vhu port e.g.) should on the same bridge(br-int). Is this necessary ? Should the tunnel port on a different bridge ? can anyone explain the reason?

Thanks
Timo

    +--------------+
    |     vm0      | 192.168.1.1/24
    +--------------+
       (vm_port0)
           |
           |
           |
    +--------------+
    |    br-int    |                                    192.168.1.2/24
    +--------------+                                   +--------------+
    |    vxlan0    |                                   |    vxlan0    |
    +--------------+                                   +--------------+
           |                                                  |
           |                                                  |
           |                                                  |
     172.168.1.1/24                                           |
    +--------------+                                          |
    |    br-phy    |                                   172.168.1.2/24
    +--------------+                                  +---------------+
    |  dpdk0/eth1  |----------------------------------|      eth1     |
    +--------------+                                  +---------------+
    Host A with OVS.                                     Remote host.


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.
> 



More information about the discuss mailing list