On Thu, Jun 13, 2024 at 02:13:27PM -0400, Aaron Conole wrote:
The OVS module can operate in conjunction with various types of tunnel ports. These are created as either explicit tunnel vport types, OR by creating a tunnel interface which acts as an anchor for the lightweight tunnel support.
This patch adds the ability to add tunnel ports to an OVS datapath for testing various scenarios with tunnel ports. With this addition, the vswitch "plumbing" will at least be able to push packets around using the tunnel vports. Future patches will add support for setting required tunnel metadata for lwts in the datapath. The end goal will be to push packets via these tunnels, and will be used in an upcoming commit for testing the path MTU.
Signed-off-by: Aaron Conole aconole@redhat.com
...
@@ -1702,12 +1711,43 @@ class OvsVport(GenericNetlinkSocket): msg["dpifindex"] = dpindex port_type = OvsVport.str_to_type(ptype)
msg["attrs"].append(["OVS_VPORT_ATTR_TYPE", port_type]) msg["attrs"].append(["OVS_VPORT_ATTR_NAME", vport_ifname]) msg["attrs"].append( ["OVS_VPORT_ATTR_UPCALL_PID", [self.upcall_packet.epid]] )
TUNNEL_DEFAULTS = [("geneve", 6081),("vxlan", 4798)]
Hi Aaron,
It is corrected as part of another patch in this series, but the correct port for vxlan is 4789 (i.e. 89 rather than 98).
With that fixed, feel free to add:
Reviewed-by: Simon Horman horms@kernel.org Tested-by: Simon Horman horms@kernel.org
..