[PATCH net-next 0/2] mlxsw: Expose number of physical ports

[PATCH net-next 0/2] mlxsw: Expose number of physical ports

[Ido Schimmel]

From: Ido Schimmel <idosch@nvidia.com>

The switch ASIC has a limited capacity of physical ports that it can
support. While each system is brought up with a different number of
ports, this number can be increased via splitting up to the ASIC's
limit.

Expose physical ports as a devlink resource so that user space will have
visibility into the maximum number of ports that can be supported and
the current occupancy. With this resource it is possible, for example,
to write generic (i.e., not platform dependent) tests for port
splitting.

Patch #1 adds the new resource and patch #2 adds a selftest.

Danielle Ratson (2):
  mlxsw: Register physical ports as a devlink resource
  selftests: mlxsw: Add a scale test for physical ports

 drivers/net/ethernet/mellanox/mlxsw/core.c    | 77 ++++++++++++++++---
 drivers/net/ethernet/mellanox/mlxsw/core.h    |  5 ++
 .../net/ethernet/mellanox/mlxsw/spectrum.h    |  2 +-
 .../selftests/drivers/net/mlxsw/port_scale.sh | 64 +++++++++++++++
 .../net/mlxsw/spectrum-2/port_scale.sh        | 16 ++++
 .../net/mlxsw/spectrum-2/resource_scale.sh    |  2 +-
 .../drivers/net/mlxsw/spectrum/port_scale.sh  | 16 ++++
 .../net/mlxsw/spectrum/resource_scale.sh      |  2 +-
 8 files changed, 171 insertions(+), 13 deletions(-)
 create mode 100644 tools/testing/selftests/drivers/net/mlxsw/port_scale.sh
 create mode 100644 tools/testing/selftests/drivers/net/mlxsw/spectrum-2/port_scale.sh
 create mode 100644 tools/testing/selftests/drivers/net/mlxsw/spectrum/port_scale.sh

-- 
2.29.2

[PATCH net-next 1/2] mlxsw: Register physical ports as a devlink resource

[Ido Schimmel]

From: Danielle Ratson <danieller@nvidia.com>

The switch ASIC has a limited capacity of physical ('flavour physical'
in devlink terminology) ports that it can support. While each system is
brought up with a different number of ports, this number can be
increased via splitting up to the ASIC's limit.

Expose physical ports as a devlink resource so that user space will have
visibility to the maximum number of ports that can be supported and the
current occupancy.

Signed-off-by: Danielle Ratson <danieller@nvidia.com>
Reviewed-by: Jiri Pirko <jiri@nvidia.com>
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
---
 drivers/net/ethernet/mellanox/mlxsw/core.c    | 77 ++++++++++++++++---
 drivers/net/ethernet/mellanox/mlxsw/core.h    |  5 ++
 .../net/ethernet/mellanox/mlxsw/spectrum.h    |  2 +-
 3 files changed, 73 insertions(+), 11 deletions(-)

diff --git a/drivers/net/ethernet/mellanox/mlxsw/core.c b/drivers/net/ethernet/mellanox/mlxsw/core.c
index 685037e052af..8e8a5188c3a5 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/core.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/core.c
@@ -84,6 +84,7 @@ struct mlxsw_core {
 	struct mlxsw_thermal *thermal;
 	struct mlxsw_core_port *ports;
 	unsigned int max_ports;
+	atomic_t active_ports_count;
 	bool fw_flash_in_progress;
 	struct {
 		struct devlink_health_reporter *fw_fatal;
@@ -95,9 +96,37 @@ struct mlxsw_core {
 };
 
 #define MLXSW_PORT_MAX_PORTS_DEFAULT	0x40
+#define MLXSW_CORE_RESOURCE_NAME_PORTS "physical_ports"
 
-static int mlxsw_ports_init(struct mlxsw_core *mlxsw_core)
+static u64 mlxsw_ports_occ_get(void *priv)
 {
+	struct mlxsw_core *mlxsw_core = priv;
+
+	return atomic_read(&mlxsw_core->active_ports_count);
+}
+
+static int mlxsw_core_resources_ports_register(struct mlxsw_core *mlxsw_core)
+{
+	struct devlink *devlink = priv_to_devlink(mlxsw_core);
+	struct devlink_resource_size_params ports_num_params;
+	u32 max_ports;
+
+	max_ports = mlxsw_core->max_ports - 1;
+	devlink_resource_size_params_init(&ports_num_params, max_ports,
+					  max_ports, 1,
+					  DEVLINK_RESOURCE_UNIT_ENTRY);
+
+	return devlink_resource_register(devlink, MLXSW_CORE_RESOURCE_NAME_PORTS,
+					 max_ports, MLXSW_CORE_RESOURCE_PORTS,
+					 DEVLINK_RESOURCE_ID_PARENT_TOP,
+					 &ports_num_params);
+}
+
+static int mlxsw_ports_init(struct mlxsw_core *mlxsw_core, bool reload)
+{
+	struct devlink *devlink = priv_to_devlink(mlxsw_core);
+	int err;
+
 	/* Switch ports are numbered from 1 to queried value */
 	if (MLXSW_CORE_RES_VALID(mlxsw_core, MAX_SYSTEM_PORT))
 		mlxsw_core->max_ports = MLXSW_CORE_RES_GET(mlxsw_core,
@@ -110,11 +139,30 @@ static int mlxsw_ports_init(struct mlxsw_core *mlxsw_core)
 	if (!mlxsw_core->ports)
 		return -ENOMEM;
 
+	if (!reload) {
+		err = mlxsw_core_resources_ports_register(mlxsw_core);
+		if (err)
+			goto err_resources_ports_register;
+	}
+	atomic_set(&mlxsw_core->active_ports_count, 0);
+	devlink_resource_occ_get_register(devlink, MLXSW_CORE_RESOURCE_PORTS,
+					  mlxsw_ports_occ_get, mlxsw_core);
+
 	return 0;
+
+err_resources_ports_register:
+	kfree(mlxsw_core->ports);
+	return err;
 }
 
-static void mlxsw_ports_fini(struct mlxsw_core *mlxsw_core)
+static void mlxsw_ports_fini(struct mlxsw_core *mlxsw_core, bool reload)
 {
+	struct devlink *devlink = priv_to_devlink(mlxsw_core);
+
+	devlink_resource_occ_get_unregister(devlink, MLXSW_CORE_RESOURCE_PORTS);
+	if (!reload)
+		devlink_resources_unregister(priv_to_devlink(mlxsw_core), NULL);
+
 	kfree(mlxsw_core->ports);
 }
 
@@ -1897,7 +1945,7 @@ __mlxsw_core_bus_device_register(const struct mlxsw_bus_info *mlxsw_bus_info,
 			goto err_register_resources;
 	}
 
-	err = mlxsw_ports_init(mlxsw_core);
+	err = mlxsw_ports_init(mlxsw_core, reload);
 	if (err)
 		goto err_ports_init;
 
@@ -1986,7 +2034,7 @@ __mlxsw_core_bus_device_register(const struct mlxsw_bus_info *mlxsw_bus_info,
 err_emad_init:
 	kfree(mlxsw_core->lag.mapping);
 err_alloc_lag_mapping:
-	mlxsw_ports_fini(mlxsw_core);
+	mlxsw_ports_fini(mlxsw_core, reload);
 err_ports_init:
 	if (!reload)
 		devlink_resources_unregister(devlink, NULL);
@@ -2056,7 +2104,7 @@ void mlxsw_core_bus_device_unregister(struct mlxsw_core *mlxsw_core,
 		devlink_unregister(devlink);
 	mlxsw_emad_fini(mlxsw_core);
 	kfree(mlxsw_core->lag.mapping);
-	mlxsw_ports_fini(mlxsw_core);
+	mlxsw_ports_fini(mlxsw_core, reload);
 	if (!reload)
 		devlink_resources_unregister(devlink, NULL);
 	mlxsw_core->bus->fini(mlxsw_core->bus_priv);
@@ -2755,16 +2803,25 @@ int mlxsw_core_port_init(struct mlxsw_core *mlxsw_core, u8 local_port,
 			 const unsigned char *switch_id,
 			 unsigned char switch_id_len)
 {
-	return __mlxsw_core_port_init(mlxsw_core, local_port,
-				      DEVLINK_PORT_FLAVOUR_PHYSICAL,
-				      port_number, split, split_port_subnumber,
-				      splittable, lanes,
-				      switch_id, switch_id_len);
+	int err;
+
+	err = __mlxsw_core_port_init(mlxsw_core, local_port,
+				     DEVLINK_PORT_FLAVOUR_PHYSICAL,
+				     port_number, split, split_port_subnumber,
+				     splittable, lanes,
+				     switch_id, switch_id_len);
+	if (err)
+		return err;
+
+	atomic_inc(&mlxsw_core->active_ports_count);
+	return 0;
 }
 EXPORT_SYMBOL(mlxsw_core_port_init);
 
 void mlxsw_core_port_fini(struct mlxsw_core *mlxsw_core, u8 local_port)
 {
+	atomic_dec(&mlxsw_core->active_ports_count);
+
 	__mlxsw_core_port_fini(mlxsw_core, local_port);
 }
 EXPORT_SYMBOL(mlxsw_core_port_fini);
diff --git a/drivers/net/ethernet/mellanox/mlxsw/core.h b/drivers/net/ethernet/mellanox/mlxsw/core.h
index 6b3ccbf6b238..8af7d9d03475 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/core.h
+++ b/drivers/net/ethernet/mellanox/mlxsw/core.h
@@ -19,6 +19,11 @@
 #include "cmd.h"
 #include "resources.h"
 
+enum mlxsw_core_resource_id {
+	MLXSW_CORE_RESOURCE_PORTS = 1,
+	MLXSW_CORE_RESOURCE_MAX,
+};
+
 struct mlxsw_core;
 struct mlxsw_core_port;
 struct mlxsw_driver;
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum.h b/drivers/net/ethernet/mellanox/mlxsw/spectrum.h
index a6956cfc9cb1..a3769f95a182 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/spectrum.h
+++ b/drivers/net/ethernet/mellanox/mlxsw/spectrum.h
@@ -52,7 +52,7 @@
 #define MLXSW_SP_RESOURCE_NAME_COUNTERS_RIF "rif"
 
 enum mlxsw_sp_resource_id {
-	MLXSW_SP_RESOURCE_KVD = 1,
+	MLXSW_SP_RESOURCE_KVD = MLXSW_CORE_RESOURCE_MAX,
 	MLXSW_SP_RESOURCE_KVD_LINEAR,
 	MLXSW_SP_RESOURCE_KVD_HASH_SINGLE,
 	MLXSW_SP_RESOURCE_KVD_HASH_DOUBLE,
-- 
2.29.2

Re: [PATCH net-next 1/2] mlxsw: Register physical ports as a devlink resource

[Jakub Kicinski]

On Tue, 12 Jan 2021 10:39:30 +0200 Ido Schimmel wrote:
> From: Danielle Ratson <danieller@nvidia.com>
> 
> The switch ASIC has a limited capacity of physical ('flavour physical'
> in devlink terminology) ports that it can support. While each system is
> brought up with a different number of ports, this number can be
> increased via splitting up to the ASIC's limit.
> 
> Expose physical ports as a devlink resource so that user space will have
> visibility to the maximum number of ports that can be supported and the
> current occupancy.

Any thoughts on making this a "generic" resource?

The limitation on number of logical ports is pretty common for switches.

Re: [PATCH net-next 1/2] mlxsw: Register physical ports as a devlink resource

[Ido Schimmel]

On Tue, Jan 12, 2021 at 08:21:22PM -0800, Jakub Kicinski wrote:
> On Tue, 12 Jan 2021 10:39:30 +0200 Ido Schimmel wrote:
> > From: Danielle Ratson <danieller@nvidia.com>
> > 
> > The switch ASIC has a limited capacity of physical ('flavour physical'
> > in devlink terminology) ports that it can support. While each system is
> > brought up with a different number of ports, this number can be
> > increased via splitting up to the ASIC's limit.
> > 
> > Expose physical ports as a devlink resource so that user space will have
> > visibility to the maximum number of ports that can be supported and the
> > current occupancy.
> 
> Any thoughts on making this a "generic" resource?

It might be possible to allow drivers to pass the maximum number of
physical ports to devlink during their initialization. Devlink can then
use it as an indication to register the resource itself instead of the
driver. It can report the current occupancy without driver intervention
since the list of ports is maintained in devlink.

There might be an issue with the resource identifier which is a 64-bit
number passed from drivers. I think we can partition this to identifiers
allocated by devlink / drivers.

Danielle / Jiri?

Re: [PATCH net-next 1/2] mlxsw: Register physical ports as a devlink resource

[Jiri Pirko]

Wed, Jan 13, 2021 at 09:32:41AM CET, idosch@idosch.org wrote:
>On Tue, Jan 12, 2021 at 08:21:22PM -0800, Jakub Kicinski wrote:
>> On Tue, 12 Jan 2021 10:39:30 +0200 Ido Schimmel wrote:
>> > From: Danielle Ratson <danieller@nvidia.com>
>> > 
>> > The switch ASIC has a limited capacity of physical ('flavour physical'
>> > in devlink terminology) ports that it can support. While each system is
>> > brought up with a different number of ports, this number can be
>> > increased via splitting up to the ASIC's limit.
>> > 
>> > Expose physical ports as a devlink resource so that user space will have
>> > visibility to the maximum number of ports that can be supported and the
>> > current occupancy.
>> 
>> Any thoughts on making this a "generic" resource?
>
>It might be possible to allow drivers to pass the maximum number of
>physical ports to devlink during their initialization. Devlink can then
>use it as an indication to register the resource itself instead of the
>driver. It can report the current occupancy without driver intervention
>since the list of ports is maintained in devlink.
>
>There might be an issue with the resource identifier which is a 64-bit
>number passed from drivers. I think we can partition this to identifiers
>allocated by devlink / drivers.
>
>Danielle / Jiri?

There is no concept of "generic resource". And I think it is a good
reason for it, as the resource is something which is always quite
hw-specific. Port number migth be one exception. Can you think of
anything else? If not, I would vote for not having "generic resource"
just for this one case.

Re: [PATCH net-next 1/2] mlxsw: Register physical ports as a devlink resource

[Ido Schimmel]

On Wed, Jan 13, 2021 at 02:39:02PM +0100, Jiri Pirko wrote:
> Wed, Jan 13, 2021 at 09:32:41AM CET, idosch@idosch.org wrote:
> >On Tue, Jan 12, 2021 at 08:21:22PM -0800, Jakub Kicinski wrote:
> >> On Tue, 12 Jan 2021 10:39:30 +0200 Ido Schimmel wrote:
> >> > From: Danielle Ratson <danieller@nvidia.com>
> >> > 
> >> > The switch ASIC has a limited capacity of physical ('flavour physical'
> >> > in devlink terminology) ports that it can support. While each system is
> >> > brought up with a different number of ports, this number can be
> >> > increased via splitting up to the ASIC's limit.
> >> > 
> >> > Expose physical ports as a devlink resource so that user space will have
> >> > visibility to the maximum number of ports that can be supported and the
> >> > current occupancy.
> >> 
> >> Any thoughts on making this a "generic" resource?
> >
> >It might be possible to allow drivers to pass the maximum number of
> >physical ports to devlink during their initialization. Devlink can then
> >use it as an indication to register the resource itself instead of the
> >driver. It can report the current occupancy without driver intervention
> >since the list of ports is maintained in devlink.
> >
> >There might be an issue with the resource identifier which is a 64-bit
> >number passed from drivers. I think we can partition this to identifiers
> >allocated by devlink / drivers.
> >
> >Danielle / Jiri?
> 
> There is no concept of "generic resource". And I think it is a good
> reason for it, as the resource is something which is always quite
> hw-specific. Port number migth be one exception. Can you think of
> anything else? If not, I would vote for not having "generic resource"
> just for this one case.

I think Jakub's point is that he does not want drivers to expose the
same resource to user space under different names. Question is how to
try to guarantee it. One option is what I suggested above, but it might
be an overkill. Another option is better documentation. To add a section
of "generic" resources in devlink-resource documentation [1] and modify
the kernel-doc comment above devlink_resource_register() to point to it.

[1] https://www.kernel.org/doc/html/latest/networking/devlink/devlink-resource.html

Re: [PATCH net-next 1/2] mlxsw: Register physical ports as a devlink resource

[Jakub Kicinski]

On Wed, 13 Jan 2021 16:26:56 +0200 Ido Schimmel wrote:
> On Wed, Jan 13, 2021 at 02:39:02PM +0100, Jiri Pirko wrote:
> > Wed, Jan 13, 2021 at 09:32:41AM CET, idosch@idosch.org wrote:  
> > >On Tue, Jan 12, 2021 at 08:21:22PM -0800, Jakub Kicinski wrote:  
> > >> On Tue, 12 Jan 2021 10:39:30 +0200 Ido Schimmel wrote:  
> > >> > From: Danielle Ratson <danieller@nvidia.com>
> > >> > 
> > >> > The switch ASIC has a limited capacity of physical ('flavour physical'
> > >> > in devlink terminology) ports that it can support. While each system is
> > >> > brought up with a different number of ports, this number can be
> > >> > increased via splitting up to the ASIC's limit.
> > >> > 
> > >> > Expose physical ports as a devlink resource so that user space will have
> > >> > visibility to the maximum number of ports that can be supported and the
> > >> > current occupancy.  
> > >> 
> > >> Any thoughts on making this a "generic" resource?  
> > >
> > >It might be possible to allow drivers to pass the maximum number of
> > >physical ports to devlink during their initialization. Devlink can then
> > >use it as an indication to register the resource itself instead of the
> > >driver. It can report the current occupancy without driver intervention
> > >since the list of ports is maintained in devlink.
> > >
> > >There might be an issue with the resource identifier which is a 64-bit
> > >number passed from drivers. I think we can partition this to identifiers
> > >allocated by devlink / drivers.
> > >
> > >Danielle / Jiri?  
> > 
> > There is no concept of "generic resource". And I think it is a good
> > reason for it, as the resource is something which is always quite
> > hw-specific. Port number migth be one exception. Can you think of
> > anything else? If not, I would vote for not having "generic resource"
> > just for this one case.  
> 
> I think Jakub's point is that he does not want drivers to expose the
> same resource to user space under different names.

Exactly.

> Question is how to
> try to guarantee it. One option is what I suggested above, but it might
> be an overkill. Another option is better documentation. To add a section
> of "generic" resources in devlink-resource documentation [1] and modify
> the kernel-doc comment above devlink_resource_register() to point to it.
> 
> [1] https://www.kernel.org/doc/html/latest/networking/devlink/devlink-resource.html

Yup, an entry in documentation and a common define in net/devlink.h
is fine by me. We can always move around the kernel internals, like 
what registers the resource, later.

[PATCH net-next 2/2] selftests: mlxsw: Add a scale test for physical ports

[Ido Schimmel]

From: Danielle Ratson <danieller@nvidia.com>

Query the maximum number of supported physical ports using devlink-resource
and test that this number can be reached by splitting each of the
splittable ports to its width. Test that an error is returned in case
the maximum number is exceeded.

Signed-off-by: Danielle Ratson <danieller@nvidia.com>
Reviewed-by: Jiri Pirko <jiri@nvidia.com>
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
---
 .../selftests/drivers/net/mlxsw/port_scale.sh | 64 +++++++++++++++++++
 .../net/mlxsw/spectrum-2/port_scale.sh        | 16 +++++
 .../net/mlxsw/spectrum-2/resource_scale.sh    |  2 +-
 .../drivers/net/mlxsw/spectrum/port_scale.sh  | 16 +++++
 .../net/mlxsw/spectrum/resource_scale.sh      |  2 +-
 5 files changed, 98 insertions(+), 2 deletions(-)
 create mode 100644 tools/testing/selftests/drivers/net/mlxsw/port_scale.sh
 create mode 100644 tools/testing/selftests/drivers/net/mlxsw/spectrum-2/port_scale.sh
 create mode 100644 tools/testing/selftests/drivers/net/mlxsw/spectrum/port_scale.sh

diff --git a/tools/testing/selftests/drivers/net/mlxsw/port_scale.sh b/tools/testing/selftests/drivers/net/mlxsw/port_scale.sh
new file mode 100644
index 000000000000..f813ffefc07e
--- /dev/null
+++ b/tools/testing/selftests/drivers/net/mlxsw/port_scale.sh
@@ -0,0 +1,64 @@
+#!/bin/bash
+# SPDX-License-Identifier: GPL-2.0
+
+# Test for physical ports resource. The test splits each splittable port
+# to its width and checks that eventually the number of physical ports equals
+# the maximum number of physical ports.
+
+PORT_NUM_NETIFS=0
+
+port_setup_prepare()
+{
+	:
+}
+
+port_cleanup()
+{
+	pre_cleanup
+
+	for port in "${unsplit[@]}"; do
+		devlink port unsplit $port
+		check_err $? "Did not unsplit $netdev"
+	done
+}
+
+split_all_ports()
+{
+	local should_fail=$1; shift
+	local -a unsplit
+
+	# Loop over the splittable netdevs and create tuples of netdev along
+	# with its width. For example:
+	# '$netdev1 $count1 $netdev2 $count2...', when:
+	# $netdev1-2 are splittable netdevs in the device, and
+	# $count1-2 are the netdevs width respectively.
+	while read netdev count <<<$(
+		devlink -j port show |
+		jq -r '.[][] | select(.splittable==true) | "\(.netdev) \(.lanes)"'
+		)
+		[[ ! -z $netdev ]]
+	do
+		devlink port split $netdev count $count
+		check_err $? "Did not split $netdev into $count"
+		unsplit+=( "${netdev}s0" )
+	done
+}
+
+port_test()
+{
+	local max_ports=$1; shift
+	local should_fail=$1; shift
+
+	split_all_ports $should_fail
+
+	occ=$(devlink -j resource show $DEVLINK_DEV \
+	      | jq '.[][][] | select(.name=="physical_ports") |.["occ"]')
+
+	[[ $occ -eq $max_ports ]]
+	if [[ $should_fail -eq 0 ]]; then
+		check_err $? "Mismatch ports number: Expected $max_ports, got $occ."
+	else
+		check_err_fail $should_fail $? "Reached more ports than expected"
+	fi
+
+}
diff --git a/tools/testing/selftests/drivers/net/mlxsw/spectrum-2/port_scale.sh b/tools/testing/selftests/drivers/net/mlxsw/spectrum-2/port_scale.sh
new file mode 100644
index 000000000000..0b71dfbbb447
--- /dev/null
+++ b/tools/testing/selftests/drivers/net/mlxsw/spectrum-2/port_scale.sh
@@ -0,0 +1,16 @@
+# SPDX-License-Identifier: GPL-2.0
+source ../port_scale.sh
+
+port_get_target()
+{
+	local should_fail=$1
+	local target
+
+	target=$(devlink_resource_size_get physical_ports)
+
+	if ((! should_fail)); then
+		echo $target
+	else
+		echo $((target + 1))
+	fi
+}
diff --git a/tools/testing/selftests/drivers/net/mlxsw/spectrum-2/resource_scale.sh b/tools/testing/selftests/drivers/net/mlxsw/spectrum-2/resource_scale.sh
index d7cf33a3f18d..4a1c9328555f 100755
--- a/tools/testing/selftests/drivers/net/mlxsw/spectrum-2/resource_scale.sh
+++ b/tools/testing/selftests/drivers/net/mlxsw/spectrum-2/resource_scale.sh
@@ -28,7 +28,7 @@ cleanup()
 
 trap cleanup EXIT
 
-ALL_TESTS="router tc_flower mirror_gre tc_police"
+ALL_TESTS="router tc_flower mirror_gre tc_police port"
 for current_test in ${TESTS:-$ALL_TESTS}; do
 	source ${current_test}_scale.sh
 
diff --git a/tools/testing/selftests/drivers/net/mlxsw/spectrum/port_scale.sh b/tools/testing/selftests/drivers/net/mlxsw/spectrum/port_scale.sh
new file mode 100644
index 000000000000..0b71dfbbb447
--- /dev/null
+++ b/tools/testing/selftests/drivers/net/mlxsw/spectrum/port_scale.sh
@@ -0,0 +1,16 @@
+# SPDX-License-Identifier: GPL-2.0
+source ../port_scale.sh
+
+port_get_target()
+{
+	local should_fail=$1
+	local target
+
+	target=$(devlink_resource_size_get physical_ports)
+
+	if ((! should_fail)); then
+		echo $target
+	else
+		echo $((target + 1))
+	fi
+}
diff --git a/tools/testing/selftests/drivers/net/mlxsw/spectrum/resource_scale.sh b/tools/testing/selftests/drivers/net/mlxsw/spectrum/resource_scale.sh
index 43f662401bc3..087a884f66cd 100755
--- a/tools/testing/selftests/drivers/net/mlxsw/spectrum/resource_scale.sh
+++ b/tools/testing/selftests/drivers/net/mlxsw/spectrum/resource_scale.sh
@@ -22,7 +22,7 @@ cleanup()
 devlink_sp_read_kvd_defaults
 trap cleanup EXIT
 
-ALL_TESTS="router tc_flower mirror_gre tc_police"
+ALL_TESTS="router tc_flower mirror_gre tc_police port"
 for current_test in ${TESTS:-$ALL_TESTS}; do
 	source ${current_test}_scale.sh
 
-- 
2.29.2