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

Ben Pfaff blp at ovn.org
Mon Jul 8 15:02:56 UTC 2019

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