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 <b...@ovn.org> > txfh2007 <txfh2...@aliyun.com> > ovs-discuss <ovs-discuss@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. > _______________________________________________ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
