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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <f7tr0cvmrhu.fsf@redhat.com>
Date: Mon, 17 Jun 2024 13:03:09 -0400
From: Aaron Conole <aconole@...hat.com>
To: Simon Horman <horms@...nel.org>
Cc: netdev@...r.kernel.org,  dev@...nvswitch.org,
  linux-kernel@...r.kernel.org,  Ilya Maximets <i.maximets@....org>,
  Stefano Brivio <sbrivio@...hat.com>,  Eric Dumazet <edumazet@...gle.com>,
  linux-kselftest@...r.kernel.org,  Jakub Kicinski <kuba@...nel.org>,
  Paolo Abeni <pabeni@...hat.com>,  Shuah Khan <shuah@...nel.org>,  "David
 S. Miller" <davem@...emloft.net>
Subject: Re: [ovs-dev] [RFC net-next 1/7] selftests: openvswitch: Support
 explicit tunnel port creation.

Simon Horman <horms@...nel.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@...hat.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@...nel.org>
> Tested-by: Simon Horman <horms@...nel.org>
>
> ..