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

txfh2007 txfh2007 at aliyun.com
Mon Jul 8 07:57:46 UTC 2019


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