Re: [ovs-dev] [RFC net-next 1/7] selftests: openvswitch: Support explicit tunnel port creation.

From: Aaron Conole
Date: Mon Jun 17 2024 - 13:03:39 EST


Simon Horman <horms@xxxxxxxxxx> writes:

> 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@xxxxxxxxxx>
>
> ...
>
>> @@ -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:

Thanks Simon! Done.

> Reviewed-by: Simon Horman <horms@xxxxxxxxxx>
> Tested-by: Simon Horman <horms@xxxxxxxxxx>
>
> ..