[ovs-git] [openvswitch/ovs] 88d2ac: ofproto-dpif: Fix continuation with patch port

Yi-Hung Wei noreply at github.com
Sat Jun 22 04:23:03 UTC 2019

  Branch: refs/heads/master
  Home:   https://github.com/openvswitch/ovs
  Commit: 88d2ac50aa4e3383e185b698a1b3a44a6f7b4f80
  Author: Yi-Hung Wei <yihung.wei at gmail.com>
  Date:   2019-06-21 (Fri, 21 Jun 2019)

  Changed paths:
    M include/openvswitch/ofp-packet.h
    M lib/ofp-packet.c
    M ofproto/ofproto-dpif-upcall.c
    M ofproto/ofproto-dpif.c
    M tests/ofproto-dpif.at

  Log Message:
  ofproto-dpif: Fix continuation with patch port

This patch fixes the ofp_port to odp_port translation issue on patch
port with nxt_resume.  When OVS resumes processing a packet from
nxt_resume, OVS does not translate the ofp in_port to odp in_port
correctly if the packet is originally received from a patch port.
Currently,OVS sets the odp in_port for this resume pakcet as ODPP_NONE
and push the resume packet back to the datapath. Later on, if the packet
goes through a recirc, OVS will generate the following message since it
can not translate odp in_port (ODPP_NONE) back to ofp in_port during upcall,
and push down a datapath rule to drop the packet.

    ofproto_dpif_upcall(handler16)|INFO|received packet on unassociated
        datapath port 4294967295

When OVS revalidates the drop datapath flow with ODPP_NONE in_port, we
will see the following warning.
    ofproto_dpif_upcall(revalidator18)|WARN|Failed to acquire udpif_key
        corresponding to unexpected flow (Invalid argument): ufid:....

This patch resolves this issue by storing the odp in_port in the
continuation messages, and restores the odp in_port before push the
packet back to the datapath.

VMWare-BZ: 2364696
Signed-off-by: Yi-Hung Wei <yihung.wei at gmail.com>
Signed-off-by: Ben Pfaff <blp at ovn.org>

More information about the git mailing list