[PATCH net 0/5] mlx5 misc fixes 2025-04-23

[PATCH net 0/5] mlx5 misc fixes 2025-04-23

[Mark Bloch]

This patchset includes misc fixes from the team for the mlx5 core
and Ethernet drivers.

Thanks,
Mark

Chris Mi (1):
  net/mlx5: E-switch, Fix error handling for enabling roce

Cosmin Ratiu (1):
  net/mlx5e: Fix lock order in mlx5e_tx_reporter_ptpsq_unhealthy_recover

Jianbo Liu (1):
  net/mlx5e: TC, Continue the attr process even if encap entry is
    invalid

Maor Gottlieb (1):
  net/mlx5: E-Switch, Initialize MAC Address for Default GID

Vlad Dogaru (1):
  net/mlx5e: Use custom tunnel header for vxlan gbp

 .../mellanox/mlx5/core/en/reporter_tx.c       |  6 ++--
 .../mellanox/mlx5/core/en/tc_tun_vxlan.c      | 32 +++++++++++++++++--
 .../net/ethernet/mellanox/mlx5/core/en_tc.c   |  5 +--
 .../mellanox/mlx5/core/eswitch_offloads.c     |  5 ++-
 .../net/ethernet/mellanox/mlx5/core/rdma.c    | 11 ++++---
 .../net/ethernet/mellanox/mlx5/core/rdma.h    |  4 +--
 6 files changed, 44 insertions(+), 19 deletions(-)


base-commit: 491ef1117c56476f199b481f8c68820fe4c3a7c2
-- 
2.34.1

[PATCH net 1/5] net/mlx5e: Use custom tunnel header for vxlan gbp

[Mark Bloch]

From: Vlad Dogaru <vdogaru@nvidia.com>

Symbolic (e.g. "vxlan") and custom (e.g. "tunnel_header_0") tunnels
cannot be combined, but the match params interface does not have fields
for matching on vxlan gbp. To match vxlan bgp, the tc_tun layer uses
tunnel_header_0.

Allow matching on both VNI and GBP by matching the VNI with a custom
tunnel header instead of the symbolic field name.

Matching solely on the VNI continues to use the symbolic field name.

Fixes: 74a778b4a63f ("net/mlx5: HWS, added definers handling")
Signed-off-by: Vlad Dogaru <vdogaru@nvidia.com>
Reviewed-by: Yevgeny Kliteynik <kliteyn@nvidia.com>
Signed-off-by: Mark Bloch <mbloch@nvidia.com>
---
 .../mellanox/mlx5/core/en/tc_tun_vxlan.c      | 32 +++++++++++++++++--
 1 file changed, 29 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en/tc_tun_vxlan.c b/drivers/net/ethernet/mellanox/mlx5/core/en/tc_tun_vxlan.c
index 5c762a71818d..7a18a469961d 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en/tc_tun_vxlan.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en/tc_tun_vxlan.c
@@ -165,9 +165,6 @@ static int mlx5e_tc_tun_parse_vxlan(struct mlx5e_priv *priv,
 	struct flow_match_enc_keyid enc_keyid;
 	void *misc_c, *misc_v;
 
-	misc_c = MLX5_ADDR_OF(fte_match_param, spec->match_criteria, misc_parameters);
-	misc_v = MLX5_ADDR_OF(fte_match_param, spec->match_value, misc_parameters);
-
 	if (!flow_rule_match_key(rule, FLOW_DISSECTOR_KEY_ENC_KEYID))
 		return 0;
 
@@ -182,6 +179,30 @@ static int mlx5e_tc_tun_parse_vxlan(struct mlx5e_priv *priv,
 		err = mlx5e_tc_tun_parse_vxlan_gbp_option(priv, spec, f);
 		if (err)
 			return err;
+
+		/* We can't mix custom tunnel headers with symbolic ones and we
+		 * don't have a symbolic field name for GBP, so we use custom
+		 * tunnel headers in this case. We need hardware support to
+		 * match on custom tunnel headers, but we already know it's
+		 * supported because the previous call successfully checked for
+		 * that.
+		 */
+		misc_c = MLX5_ADDR_OF(fte_match_param, spec->match_criteria,
+				      misc_parameters_5);
+		misc_v = MLX5_ADDR_OF(fte_match_param, spec->match_value,
+				      misc_parameters_5);
+
+		/* Shift by 8 to account for the reserved bits in the vxlan
+		 * header after the VNI.
+		 */
+		MLX5_SET(fte_match_set_misc5, misc_c, tunnel_header_1,
+			 be32_to_cpu(enc_keyid.mask->keyid) << 8);
+		MLX5_SET(fte_match_set_misc5, misc_v, tunnel_header_1,
+			 be32_to_cpu(enc_keyid.key->keyid) << 8);
+
+		spec->match_criteria_enable |= MLX5_MATCH_MISC_PARAMETERS_5;
+
+		return 0;
 	}
 
 	/* match on VNI is required */
@@ -195,6 +216,11 @@ static int mlx5e_tc_tun_parse_vxlan(struct mlx5e_priv *priv,
 		return -EOPNOTSUPP;
 	}
 
+	misc_c = MLX5_ADDR_OF(fte_match_param, spec->match_criteria,
+			      misc_parameters);
+	misc_v = MLX5_ADDR_OF(fte_match_param, spec->match_value,
+			      misc_parameters);
+
 	MLX5_SET(fte_match_set_misc, misc_c, vxlan_vni,
 		 be32_to_cpu(enc_keyid.mask->keyid));
 	MLX5_SET(fte_match_set_misc, misc_v, vxlan_vni,
-- 
2.34.1

[PATCH net 2/5] net/mlx5: E-Switch, Initialize MAC Address for Default GID

[Mark Bloch]

From: Maor Gottlieb <maorg@nvidia.com>

Initialize the source MAC address when creating the default GID entry.
Since this entry is used only for loopback traffic, it only needs to
be a unicast address. A zeroed-out MAC address is sufficient for this
purpose.
Without this fix, random bits would be assigned as the source address.
If these bits formed a multicast address, the firmware would return an
error, preventing the user from switching to switchdev mode:

Error: mlx5_core: Failed setting eswitch to offloads.
kernel answers: Invalid argument

Fixes: 80f09dfc237f ("net/mlx5: Eswitch, enable RoCE loopback traffic")
Signed-off-by: Maor Gottlieb <maorg@nvidia.com>
Signed-off-by: Mark Bloch <mbloch@nvidia.com>
---
 drivers/net/ethernet/mellanox/mlx5/core/rdma.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/mellanox/mlx5/core/rdma.c b/drivers/net/ethernet/mellanox/mlx5/core/rdma.c
index a42f6cd99b74..f585ef5a3424 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/rdma.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/rdma.c
@@ -118,8 +118,8 @@ static void mlx5_rdma_make_default_gid(struct mlx5_core_dev *dev, union ib_gid *
 
 static int mlx5_rdma_add_roce_addr(struct mlx5_core_dev *dev)
 {
+	u8 mac[ETH_ALEN] = {};
 	union ib_gid gid;
-	u8 mac[ETH_ALEN];
 
 	mlx5_rdma_make_default_gid(dev, &gid);
 	return mlx5_core_roce_gid_set(dev, 0,
-- 
2.34.1

[PATCH net 3/5] net/mlx5e: TC, Continue the attr process even if encap entry is invalid

[Mark Bloch]

From: Jianbo Liu <jianbol@nvidia.com>

Previously the offload of the rule with header rewrite and mirror to
both internal and external destinations is skipped if the encap entry
is not valid. But it shouldn't because driver will try to offload it
again if neighbor is updated and encap entry is valid, to replace the
old FTE added for slow path. But the extra split attr doesn't exist at
that time as the process is skipped, driver then fails to offload it.
To fix this issue, remove the checking and continue the attr process
if encap entry is invalid.

Fixes: b11bde56246e ("net/mlx5e: TC, Offload rewrite and mirror to both internal and external dests")
Signed-off-by: Jianbo Liu <jianbol@nvidia.com>
Reviewed-by: Cosmin Ratiu <cratiu@nvidia.com>
Signed-off-by: Mark Bloch <mbloch@nvidia.com>
---
 drivers/net/ethernet/mellanox/mlx5/core/en_tc.c | 5 +----
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c b/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
index 9ba99609999f..f1d908f61134 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
@@ -1750,9 +1750,6 @@ extra_split_attr_dests_needed(struct mlx5e_tc_flow *flow, struct mlx5_flow_attr
 	    !list_is_first(&attr->list, &flow->attrs))
 		return 0;
 
-	if (flow_flag_test(flow, SLOW))
-		return 0;
-
 	esw_attr = attr->esw_attr;
 	if (!esw_attr->split_count ||
 	    esw_attr->split_count == esw_attr->out_count - 1)
@@ -1766,7 +1763,7 @@ extra_split_attr_dests_needed(struct mlx5e_tc_flow *flow, struct mlx5_flow_attr
 	for (i = esw_attr->split_count; i < esw_attr->out_count; i++) {
 		/* external dest with encap is considered as internal by firmware */
 		if (esw_attr->dests[i].vport == MLX5_VPORT_UPLINK &&
-		    !(esw_attr->dests[i].flags & MLX5_ESW_DEST_ENCAP_VALID))
+		    !(esw_attr->dests[i].flags & MLX5_ESW_DEST_ENCAP))
 			ext_dest = true;
 		else
 			int_dest = true;
-- 
2.34.1

[PATCH net 4/5] net/mlx5e: Fix lock order in mlx5e_tx_reporter_ptpsq_unhealthy_recover

[Mark Bloch]

From: Cosmin Ratiu <cratiu@nvidia.com>

RTNL needs to be acquired before state_lock.

Fixes: fdce06bda7e5 ("net/mlx5e: Acquire RTNL lock before RQs/SQs activation/deactivation")
Signed-off-by: Cosmin Ratiu <cratiu@nvidia.com>
Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com>
Signed-off-by: Mark Bloch <mbloch@nvidia.com>
---
 drivers/net/ethernet/mellanox/mlx5/core/en/reporter_tx.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en/reporter_tx.c b/drivers/net/ethernet/mellanox/mlx5/core/en/reporter_tx.c
index 532c7fa94d17..dbd9482359e1 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en/reporter_tx.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en/reporter_tx.c
@@ -176,6 +176,7 @@ static int mlx5e_tx_reporter_ptpsq_unhealthy_recover(void *ctx)
 
 	priv = ptpsq->txqsq.priv;
 
+	rtnl_lock();
 	mutex_lock(&priv->state_lock);
 	chs = &priv->channels;
 	netdev = priv->netdev;
@@ -183,22 +184,19 @@ static int mlx5e_tx_reporter_ptpsq_unhealthy_recover(void *ctx)
 	carrier_ok = netif_carrier_ok(netdev);
 	netif_carrier_off(netdev);
 
-	rtnl_lock();
 	mlx5e_deactivate_priv_channels(priv);
-	rtnl_unlock();
 
 	mlx5e_ptp_close(chs->ptp);
 	err = mlx5e_ptp_open(priv, &chs->params, chs->c[0]->lag_port, &chs->ptp);
 
-	rtnl_lock();
 	mlx5e_activate_priv_channels(priv);
-	rtnl_unlock();
 
 	/* return carrier back if needed */
 	if (carrier_ok)
 		netif_carrier_on(netdev);
 
 	mutex_unlock(&priv->state_lock);
+	rtnl_unlock();
 
 	return err;
 }
-- 
2.34.1

[PATCH net 5/5] net/mlx5: E-switch, Fix error handling for enabling roce

[Mark Bloch]

From: Chris Mi <cmi@nvidia.com>

The cited commit assumes enabling roce always succeeds. But it is
not true. Add error handling for it.

Fixes: 80f09dfc237f ("net/mlx5: Eswitch, enable RoCE loopback traffic")
Signed-off-by: Chris Mi <cmi@nvidia.com>
Reviewed-by: Roi Dayan <roid@nvidia.com>
Reviewed-by: Maor Gottlieb <maorg@nvidia.com>
Signed-off-by: Mark Bloch <mbloch@nvidia.com>
---
 .../net/ethernet/mellanox/mlx5/core/eswitch_offloads.c   | 5 ++++-
 drivers/net/ethernet/mellanox/mlx5/core/rdma.c           | 9 +++++----
 drivers/net/ethernet/mellanox/mlx5/core/rdma.h           | 4 ++--
 3 files changed, 11 insertions(+), 7 deletions(-)

diff --git a/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c b/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
index a6a8eea5980c..0e3a977d5332 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
@@ -3533,7 +3533,9 @@ int esw_offloads_enable(struct mlx5_eswitch *esw)
 	int err;
 
 	mutex_init(&esw->offloads.termtbl_mutex);
-	mlx5_rdma_enable_roce(esw->dev);
+	err = mlx5_rdma_enable_roce(esw->dev);
+	if (err)
+		goto err_roce;
 
 	err = mlx5_esw_host_number_init(esw);
 	if (err)
@@ -3594,6 +3596,7 @@ int esw_offloads_enable(struct mlx5_eswitch *esw)
 	esw_offloads_metadata_uninit(esw);
 err_metadata:
 	mlx5_rdma_disable_roce(esw->dev);
+err_roce:
 	mutex_destroy(&esw->offloads.termtbl_mutex);
 	return err;
 }
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/rdma.c b/drivers/net/ethernet/mellanox/mlx5/core/rdma.c
index f585ef5a3424..5c552b71e371 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/rdma.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/rdma.c
@@ -140,17 +140,17 @@ void mlx5_rdma_disable_roce(struct mlx5_core_dev *dev)
 	mlx5_nic_vport_disable_roce(dev);
 }
 
-void mlx5_rdma_enable_roce(struct mlx5_core_dev *dev)
+int mlx5_rdma_enable_roce(struct mlx5_core_dev *dev)
 {
 	int err;
 
 	if (!MLX5_CAP_GEN(dev, roce))
-		return;
+		return 0;
 
 	err = mlx5_nic_vport_enable_roce(dev);
 	if (err) {
 		mlx5_core_err(dev, "Failed to enable RoCE: %d\n", err);
-		return;
+		return err;
 	}
 
 	err = mlx5_rdma_add_roce_addr(dev);
@@ -165,10 +165,11 @@ void mlx5_rdma_enable_roce(struct mlx5_core_dev *dev)
 		goto del_roce_addr;
 	}
 
-	return;
+	return err;
 
 del_roce_addr:
 	mlx5_rdma_del_roce_addr(dev);
 disable_roce:
 	mlx5_nic_vport_disable_roce(dev);
+	return err;
 }
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/rdma.h b/drivers/net/ethernet/mellanox/mlx5/core/rdma.h
index 750cff2a71a4..3d9e76c3d42f 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/rdma.h
+++ b/drivers/net/ethernet/mellanox/mlx5/core/rdma.h
@@ -8,12 +8,12 @@
 
 #ifdef CONFIG_MLX5_ESWITCH
 
-void mlx5_rdma_enable_roce(struct mlx5_core_dev *dev);
+int mlx5_rdma_enable_roce(struct mlx5_core_dev *dev);
 void mlx5_rdma_disable_roce(struct mlx5_core_dev *dev);
 
 #else /* CONFIG_MLX5_ESWITCH */
 
-static inline void mlx5_rdma_enable_roce(struct mlx5_core_dev *dev) {}
+static inline int mlx5_rdma_enable_roce(struct mlx5_core_dev *dev) { return 0; }
 static inline void mlx5_rdma_disable_roce(struct mlx5_core_dev *dev) {}
 
 #endif /* CONFIG_MLX5_ESWITCH */
-- 
2.34.1

Re: [PATCH net 5/5] net/mlx5: E-switch, Fix error handling for enabling roce

[Michal Swiatkowski]

On Wed, Apr 23, 2025 at 11:36:11AM +0300, Mark Bloch wrote:
> From: Chris Mi <cmi@nvidia.com>
> 
> The cited commit assumes enabling roce always succeeds. But it is
> not true. Add error handling for it.
> 
> Fixes: 80f09dfc237f ("net/mlx5: Eswitch, enable RoCE loopback traffic")
> Signed-off-by: Chris Mi <cmi@nvidia.com>
> Reviewed-by: Roi Dayan <roid@nvidia.com>
> Reviewed-by: Maor Gottlieb <maorg@nvidia.com>
> Signed-off-by: Mark Bloch <mbloch@nvidia.com>
> ---
>  .../net/ethernet/mellanox/mlx5/core/eswitch_offloads.c   | 5 ++++-
>  drivers/net/ethernet/mellanox/mlx5/core/rdma.c           | 9 +++++----
>  drivers/net/ethernet/mellanox/mlx5/core/rdma.h           | 4 ++--
>  3 files changed, 11 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c b/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
> index a6a8eea5980c..0e3a977d5332 100644
> --- a/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
> @@ -3533,7 +3533,9 @@ int esw_offloads_enable(struct mlx5_eswitch *esw)
>  	int err;
>  
>  	mutex_init(&esw->offloads.termtbl_mutex);
> -	mlx5_rdma_enable_roce(esw->dev);
> +	err = mlx5_rdma_enable_roce(esw->dev);
> +	if (err)
> +		goto err_roce;
>  
>  	err = mlx5_esw_host_number_init(esw);
>  	if (err)
> @@ -3594,6 +3596,7 @@ int esw_offloads_enable(struct mlx5_eswitch *esw)
>  	esw_offloads_metadata_uninit(esw);
>  err_metadata:
>  	mlx5_rdma_disable_roce(esw->dev);
> +err_roce:
>  	mutex_destroy(&esw->offloads.termtbl_mutex);
>  	return err;
>  }
> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/rdma.c b/drivers/net/ethernet/mellanox/mlx5/core/rdma.c
> index f585ef5a3424..5c552b71e371 100644
> --- a/drivers/net/ethernet/mellanox/mlx5/core/rdma.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/rdma.c
> @@ -140,17 +140,17 @@ void mlx5_rdma_disable_roce(struct mlx5_core_dev *dev)
>  	mlx5_nic_vport_disable_roce(dev);
>  }
>  
> -void mlx5_rdma_enable_roce(struct mlx5_core_dev *dev)
> +int mlx5_rdma_enable_roce(struct mlx5_core_dev *dev)
>  {
>  	int err;
>  
>  	if (!MLX5_CAP_GEN(dev, roce))
> -		return;
> +		return 0;
>  
>  	err = mlx5_nic_vport_enable_roce(dev);
>  	if (err) {
>  		mlx5_core_err(dev, "Failed to enable RoCE: %d\n", err);
> -		return;
> +		return err;
>  	}
>  
>  	err = mlx5_rdma_add_roce_addr(dev);
> @@ -165,10 +165,11 @@ void mlx5_rdma_enable_roce(struct mlx5_core_dev *dev)
>  		goto del_roce_addr;
>  	}
>  
> -	return;
> +	return err;
>  
>  del_roce_addr:
>  	mlx5_rdma_del_roce_addr(dev);
>  disable_roce:
>  	mlx5_nic_vport_disable_roce(dev);
> +	return err;
>  }
> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/rdma.h b/drivers/net/ethernet/mellanox/mlx5/core/rdma.h
> index 750cff2a71a4..3d9e76c3d42f 100644
> --- a/drivers/net/ethernet/mellanox/mlx5/core/rdma.h
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/rdma.h
> @@ -8,12 +8,12 @@
>  
>  #ifdef CONFIG_MLX5_ESWITCH
>  
> -void mlx5_rdma_enable_roce(struct mlx5_core_dev *dev);
> +int mlx5_rdma_enable_roce(struct mlx5_core_dev *dev);
>  void mlx5_rdma_disable_roce(struct mlx5_core_dev *dev);
>  
>  #else /* CONFIG_MLX5_ESWITCH */
>  
> -static inline void mlx5_rdma_enable_roce(struct mlx5_core_dev *dev) {}
> +static inline int mlx5_rdma_enable_roce(struct mlx5_core_dev *dev) { return 0; }
>  static inline void mlx5_rdma_disable_roce(struct mlx5_core_dev *dev) {}
>  
>  #endif /* CONFIG_MLX5_ESWITCH */

Reviewed-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com>

> -- 
> 2.34.1

Re: [PATCH net 2/5] net/mlx5: E-Switch, Initialize MAC Address for Default GID

[Michal Swiatkowski]

On Wed, Apr 23, 2025 at 11:36:08AM +0300, Mark Bloch wrote:
> From: Maor Gottlieb <maorg@nvidia.com>
> 
> Initialize the source MAC address when creating the default GID entry.
> Since this entry is used only for loopback traffic, it only needs to
> be a unicast address. A zeroed-out MAC address is sufficient for this
> purpose.
> Without this fix, random bits would be assigned as the source address.
> If these bits formed a multicast address, the firmware would return an
> error, preventing the user from switching to switchdev mode:
> 
> Error: mlx5_core: Failed setting eswitch to offloads.
> kernel answers: Invalid argument
> 
> Fixes: 80f09dfc237f ("net/mlx5: Eswitch, enable RoCE loopback traffic")
> Signed-off-by: Maor Gottlieb <maorg@nvidia.com>
> Signed-off-by: Mark Bloch <mbloch@nvidia.com>
> ---
>  drivers/net/ethernet/mellanox/mlx5/core/rdma.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/rdma.c b/drivers/net/ethernet/mellanox/mlx5/core/rdma.c
> index a42f6cd99b74..f585ef5a3424 100644
> --- a/drivers/net/ethernet/mellanox/mlx5/core/rdma.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/rdma.c
> @@ -118,8 +118,8 @@ static void mlx5_rdma_make_default_gid(struct mlx5_core_dev *dev, union ib_gid *
>  
>  static int mlx5_rdma_add_roce_addr(struct mlx5_core_dev *dev)
>  {
> +	u8 mac[ETH_ALEN] = {};

Won't it be helpful to add comment that it needs to be unicast and 0 is
a valid MAC?

Anyway,
Reviewed-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com>

hw_id in mlx5_rdma_make_default_gid() is also used without assigining.
Is it fine to have random bits there?

Thanks

>  	union ib_gid gid;
> -	u8 mac[ETH_ALEN];
>  
>  	mlx5_rdma_make_default_gid(dev, &gid);
>  	return mlx5_core_roce_gid_set(dev, 0,
> -- 
> 2.34.1

Re: [PATCH net 1/5] net/mlx5e: Use custom tunnel header for vxlan gbp

[Michal Swiatkowski]

On Wed, Apr 23, 2025 at 11:36:07AM +0300, Mark Bloch wrote:
> From: Vlad Dogaru <vdogaru@nvidia.com>
> 
> Symbolic (e.g. "vxlan") and custom (e.g. "tunnel_header_0") tunnels
> cannot be combined, but the match params interface does not have fields
> for matching on vxlan gbp. To match vxlan bgp, the tc_tun layer uses
> tunnel_header_0.
> 
> Allow matching on both VNI and GBP by matching the VNI with a custom
> tunnel header instead of the symbolic field name.
> 
> Matching solely on the VNI continues to use the symbolic field name.
> 
> Fixes: 74a778b4a63f ("net/mlx5: HWS, added definers handling")
> Signed-off-by: Vlad Dogaru <vdogaru@nvidia.com>
> Reviewed-by: Yevgeny Kliteynik <kliteyn@nvidia.com>
> Signed-off-by: Mark Bloch <mbloch@nvidia.com>
> ---
>  .../mellanox/mlx5/core/en/tc_tun_vxlan.c      | 32 +++++++++++++++++--
>  1 file changed, 29 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en/tc_tun_vxlan.c b/drivers/net/ethernet/mellanox/mlx5/core/en/tc_tun_vxlan.c
> index 5c762a71818d..7a18a469961d 100644
> --- a/drivers/net/ethernet/mellanox/mlx5/core/en/tc_tun_vxlan.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/en/tc_tun_vxlan.c
> @@ -165,9 +165,6 @@ static int mlx5e_tc_tun_parse_vxlan(struct mlx5e_priv *priv,
>  	struct flow_match_enc_keyid enc_keyid;
>  	void *misc_c, *misc_v;
>  
> -	misc_c = MLX5_ADDR_OF(fte_match_param, spec->match_criteria, misc_parameters);
> -	misc_v = MLX5_ADDR_OF(fte_match_param, spec->match_value, misc_parameters);
> -
>  	if (!flow_rule_match_key(rule, FLOW_DISSECTOR_KEY_ENC_KEYID))
>  		return 0;
>  
> @@ -182,6 +179,30 @@ static int mlx5e_tc_tun_parse_vxlan(struct mlx5e_priv *priv,
>  		err = mlx5e_tc_tun_parse_vxlan_gbp_option(priv, spec, f);
>  		if (err)
>  			return err;
> +
> +		/* We can't mix custom tunnel headers with symbolic ones and we
> +		 * don't have a symbolic field name for GBP, so we use custom
> +		 * tunnel headers in this case. We need hardware support to
> +		 * match on custom tunnel headers, but we already know it's
> +		 * supported because the previous call successfully checked for
> +		 * that.
> +		 */
> +		misc_c = MLX5_ADDR_OF(fte_match_param, spec->match_criteria,
> +				      misc_parameters_5);
> +		misc_v = MLX5_ADDR_OF(fte_match_param, spec->match_value,
> +				      misc_parameters_5);
> +
> +		/* Shift by 8 to account for the reserved bits in the vxlan
> +		 * header after the VNI.
> +		 */
> +		MLX5_SET(fte_match_set_misc5, misc_c, tunnel_header_1,
> +			 be32_to_cpu(enc_keyid.mask->keyid) << 8);
> +		MLX5_SET(fte_match_set_misc5, misc_v, tunnel_header_1,
> +			 be32_to_cpu(enc_keyid.key->keyid) << 8);
> +
> +		spec->match_criteria_enable |= MLX5_MATCH_MISC_PARAMETERS_5;
> +
> +		return 0;
>  	}
>  
>  	/* match on VNI is required */
> @@ -195,6 +216,11 @@ static int mlx5e_tc_tun_parse_vxlan(struct mlx5e_priv *priv,
>  		return -EOPNOTSUPP;
>  	}
>  
> +	misc_c = MLX5_ADDR_OF(fte_match_param, spec->match_criteria,
> +			      misc_parameters);
> +	misc_v = MLX5_ADDR_OF(fte_match_param, spec->match_value,
> +			      misc_parameters);
> +
>  	MLX5_SET(fte_match_set_misc, misc_c, vxlan_vni,
>  		 be32_to_cpu(enc_keyid.mask->keyid));
>  	MLX5_SET(fte_match_set_misc, misc_v, vxlan_vni,

Reviewed-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com>

> -- 
> 2.34.1

Re: [PATCH net 2/5] net/mlx5: E-Switch, Initialize MAC Address for Default GID

[Mark Bloch]

On 23/04/2025 13:31, Michal Swiatkowski wrote:
> On Wed, Apr 23, 2025 at 11:36:08AM +0300, Mark Bloch wrote:
>> From: Maor Gottlieb <maorg@nvidia.com>
>>
>> Initialize the source MAC address when creating the default GID entry.
>> Since this entry is used only for loopback traffic, it only needs to
>> be a unicast address. A zeroed-out MAC address is sufficient for this
>> purpose.
>> Without this fix, random bits would be assigned as the source address.
>> If these bits formed a multicast address, the firmware would return an
>> error, preventing the user from switching to switchdev mode:
>>
>> Error: mlx5_core: Failed setting eswitch to offloads.
>> kernel answers: Invalid argument
>>
>> Fixes: 80f09dfc237f ("net/mlx5: Eswitch, enable RoCE loopback traffic")
>> Signed-off-by: Maor Gottlieb <maorg@nvidia.com>
>> Signed-off-by: Mark Bloch <mbloch@nvidia.com>
>> ---
>>  drivers/net/ethernet/mellanox/mlx5/core/rdma.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/rdma.c b/drivers/net/ethernet/mellanox/mlx5/core/rdma.c
>> index a42f6cd99b74..f585ef5a3424 100644
>> --- a/drivers/net/ethernet/mellanox/mlx5/core/rdma.c
>> +++ b/drivers/net/ethernet/mellanox/mlx5/core/rdma.c
>> @@ -118,8 +118,8 @@ static void mlx5_rdma_make_default_gid(struct mlx5_core_dev *dev, union ib_gid *
>>  
>>  static int mlx5_rdma_add_roce_addr(struct mlx5_core_dev *dev)
>>  {
>> +	u8 mac[ETH_ALEN] = {};
> 
> Won't it be helpful to add comment that it needs to be unicast and 0 is
> a valid MAC?

That's why the commit message has: "it only needs to
be a unicast address. A zeroed-out MAC address is sufficient for this
purpose."

I feel this is good enough.

> 
> Anyway,
> Reviewed-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com>

Thanks!

> 
> hw_id in mlx5_rdma_make_default_gid() is also used without assigining.
> Is it fine to have random bits there?

We pass hw_id to mlx5_query_mac_address() which fills it.
However, there's a separate issue where mlx5_query_mac_address()
might fail, this is unlikely, but still possible.
We'll address that in a follow-up patch.

Thanks for the review! 

Mark

> 
> Thanks
> 
>>  	union ib_gid gid;
>> -	u8 mac[ETH_ALEN];
>>  
>>  	mlx5_rdma_make_default_gid(dev, &gid);
>>  	return mlx5_core_roce_gid_set(dev, 0,
>> -- 
>> 2.34.1

Re: [PATCH net 2/5] net/mlx5: E-Switch, Initialize MAC Address for Default GID

[Michal Swiatkowski]

On Wed, Apr 23, 2025 at 02:20:56PM +0300, Mark Bloch wrote:
> 
> 
> On 23/04/2025 13:31, Michal Swiatkowski wrote:
> > On Wed, Apr 23, 2025 at 11:36:08AM +0300, Mark Bloch wrote:
> >> From: Maor Gottlieb <maorg@nvidia.com>
> >>
> >> Initialize the source MAC address when creating the default GID entry.
> >> Since this entry is used only for loopback traffic, it only needs to
> >> be a unicast address. A zeroed-out MAC address is sufficient for this
> >> purpose.
> >> Without this fix, random bits would be assigned as the source address.
> >> If these bits formed a multicast address, the firmware would return an
> >> error, preventing the user from switching to switchdev mode:
> >>
> >> Error: mlx5_core: Failed setting eswitch to offloads.
> >> kernel answers: Invalid argument
> >>
> >> Fixes: 80f09dfc237f ("net/mlx5: Eswitch, enable RoCE loopback traffic")
> >> Signed-off-by: Maor Gottlieb <maorg@nvidia.com>
> >> Signed-off-by: Mark Bloch <mbloch@nvidia.com>
> >> ---
> >>  drivers/net/ethernet/mellanox/mlx5/core/rdma.c | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/rdma.c b/drivers/net/ethernet/mellanox/mlx5/core/rdma.c
> >> index a42f6cd99b74..f585ef5a3424 100644
> >> --- a/drivers/net/ethernet/mellanox/mlx5/core/rdma.c
> >> +++ b/drivers/net/ethernet/mellanox/mlx5/core/rdma.c
> >> @@ -118,8 +118,8 @@ static void mlx5_rdma_make_default_gid(struct mlx5_core_dev *dev, union ib_gid *
> >>  
> >>  static int mlx5_rdma_add_roce_addr(struct mlx5_core_dev *dev)
> >>  {
> >> +	u8 mac[ETH_ALEN] = {};
> > 
> > Won't it be helpful to add comment that it needs to be unicast and 0 is
> > a valid MAC?
> 
> That's why the commit message has: "it only needs to
> be a unicast address. A zeroed-out MAC address is sufficient for this
> purpose."
> 
> I feel this is good enough.

Make sense, thanks

> 
> > 
> > Anyway,
> > Reviewed-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com>
> 
> Thanks!
> 
> > 
> > hw_id in mlx5_rdma_make_default_gid() is also used without assigining.
> > Is it fine to have random bits there?
> 
> We pass hw_id to mlx5_query_mac_address() which fills it.
> However, there's a separate issue where mlx5_query_mac_address()
> might fail, this is unlikely, but still possible.
> We'll address that in a follow-up patch.
> 
> Thanks for the review! 
> 
> Mark
> 
> > 
> > Thanks
> > 
> >>  	union ib_gid gid;
> >> -	u8 mac[ETH_ALEN];
> >>  
> >>  	mlx5_rdma_make_default_gid(dev, &gid);
> >>  	return mlx5_core_roce_gid_set(dev, 0,
> >> -- 
> >> 2.34.1
> 

Re: [PATCH net 0/5] mlx5 misc fixes 2025-04-23

[patchwork-bot+netdevbpf]

Hello:

This series was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:

On Wed, 23 Apr 2025 11:36:06 +0300 you wrote:
> This patchset includes misc fixes from the team for the mlx5 core
> and Ethernet drivers.
> 
> Thanks,
> Mark
> 
> Chris Mi (1):
>   net/mlx5: E-switch, Fix error handling for enabling roce
> 
> [...]

Here is the summary with links:
  - [net,1/5] net/mlx5e: Use custom tunnel header for vxlan gbp
    https://git.kernel.org/netdev/net/c/eacc77a73275
  - [net,2/5] net/mlx5: E-Switch, Initialize MAC Address for Default GID
    https://git.kernel.org/netdev/net/c/5d1a04f347e6
  - [net,3/5] net/mlx5e: TC, Continue the attr process even if encap entry is invalid
    https://git.kernel.org/netdev/net/c/172c034264c8
  - [net,4/5] net/mlx5e: Fix lock order in mlx5e_tx_reporter_ptpsq_unhealthy_recover
    https://git.kernel.org/netdev/net/c/1c2940ec0ddf
  - [net,5/5] net/mlx5: E-switch, Fix error handling for enabling roce
    https://git.kernel.org/netdev/net/c/90538d23278a

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html