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

[Aaron Conole <aconole@redhat.com>]

Simon Horman <horms@kernel.org> 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@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:

Thanks Simon!  Done.

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