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 [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
