[PATCH net-next V2 0/2] net/mlx5e: misc changes 2025-07-22

[PATCH net-next V2 0/2] net/mlx5e: misc changes 2025-07-22

[Tariq Toukan]

Hi,

This series contains misc enhancements to the mlx5e driver.
This is V2. Previous one was deferred, find it here:
https://lore.kernel.org/all/1752771792-265762-1-git-send-email-tariqt@nvidia.com/

Regards,
Tariq

V2:
- Fixed RCT issue in patch #1.
- Dropped patch #2, the same as
https://patchwork.kernel.org/project/linux-rdma/patch/20250711030359.4419-1-yanjun.zhu@linux.dev/

Alexandre Cassen (1):
  net/mlx5e: Support routed networks during IPsec MACs initialization

Feng Liu (1):
  net/mlx5e: Expose TIS via devlink tx reporter diagnose

 .../mellanox/mlx5/core/en/reporter_tx.c       | 25 ++++++
 .../mellanox/mlx5/core/en_accel/ipsec.c       | 82 ++++++++++++++++++-
 2 files changed, 105 insertions(+), 2 deletions(-)


base-commit: 3fc894728fb3a0d9282e81247b68c07468fe2985
-- 
2.31.1

[PATCH net-next V2 1/2] net/mlx5e: Support routed networks during IPsec MACs initialization

[Tariq Toukan]

From: Alexandre Cassen <acassen@corp.free.fr>

Remote IPsec tunnel endpoint may refer to a network segment that is
not directly connected to the host. In such a case, IPsec tunnel
endpoints are connected to a router and reachable via a routing path.
In IPsec packet offload mode, HW is initialized with the MAC address
of both IPsec tunnel endpoints.

Extend the current IPsec init MACs procedure to resolve nexthop for
routed networks. Direct neighbour lookup and probe is still used
for directly connected networks and as a fallback mechanism if fib
lookup fails.

Signed-off-by: Alexandre Cassen <acassen@corp.free.fr>
Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
Reviewed-by: Cosmin Ratiu <cratiu@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
---
 .../mellanox/mlx5/core/en_accel/ipsec.c       | 82 ++++++++++++++++++-
 1 file changed, 80 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ipsec.c b/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ipsec.c
index 77f61cd28a79..00e77c71e201 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ipsec.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ipsec.c
@@ -36,6 +36,7 @@
 #include <linux/inetdevice.h>
 #include <linux/netdevice.h>
 #include <net/netevent.h>
+#include <net/ipv6_stubs.h>
 
 #include "en.h"
 #include "eswitch.h"
@@ -259,9 +260,15 @@ static void mlx5e_ipsec_init_macs(struct mlx5e_ipsec_sa_entry *sa_entry,
 				  struct mlx5_accel_esp_xfrm_attrs *attrs)
 {
 	struct mlx5_core_dev *mdev = mlx5e_ipsec_sa2dev(sa_entry);
+	struct mlx5e_ipsec_addr *addrs = &attrs->addrs;
 	struct net_device *netdev = sa_entry->dev;
+	struct xfrm_state *x = sa_entry->x;
+	struct dst_entry *rt_dst_entry;
+	struct flowi4 fl4 = {};
+	struct flowi6 fl6 = {};
 	struct neighbour *n;
 	u8 addr[ETH_ALEN];
+	struct rtable *rt;
 	const void *pkey;
 	u8 *dst, *src;
 
@@ -274,18 +281,89 @@ static void mlx5e_ipsec_init_macs(struct mlx5e_ipsec_sa_entry *sa_entry,
 	case XFRM_DEV_OFFLOAD_IN:
 		src = attrs->dmac;
 		dst = attrs->smac;
-		pkey = &attrs->addrs.saddr.a4;
+
+		switch (addrs->family) {
+		case AF_INET:
+			fl4.flowi4_proto = x->sel.proto;
+			fl4.daddr = addrs->saddr.a4;
+			fl4.saddr = addrs->daddr.a4;
+			pkey = &addrs->saddr.a4;
+			break;
+		case AF_INET6:
+			fl6.flowi6_proto = x->sel.proto;
+			memcpy(fl6.daddr.s6_addr32, addrs->saddr.a6, 16);
+			memcpy(fl6.saddr.s6_addr32, addrs->daddr.a6, 16);
+			pkey = &addrs->saddr.a6;
+			break;
+		default:
+			return;
+		}
 		break;
 	case XFRM_DEV_OFFLOAD_OUT:
 		src = attrs->smac;
 		dst = attrs->dmac;
-		pkey = &attrs->addrs.daddr.a4;
+		switch (addrs->family) {
+		case AF_INET:
+			fl4.flowi4_proto = x->sel.proto;
+			fl4.daddr = addrs->daddr.a4;
+			fl4.saddr = addrs->saddr.a4;
+			pkey = &addrs->daddr.a4;
+			break;
+		case AF_INET6:
+			fl6.flowi6_proto = x->sel.proto;
+			memcpy(fl6.daddr.s6_addr32, addrs->daddr.a6, 16);
+			memcpy(fl6.saddr.s6_addr32, addrs->saddr.a6, 16);
+			pkey = &addrs->daddr.a6;
+			break;
+		default:
+			return;
+		}
 		break;
 	default:
 		return;
 	}
 
 	ether_addr_copy(src, addr);
+
+	/* Destination can refer to a routed network, so perform FIB lookup
+	 * to resolve nexthop and get its MAC. Neighbour resolution is used as
+	 * fallback.
+	 */
+	switch (addrs->family) {
+	case AF_INET:
+		rt = ip_route_output_key(dev_net(netdev), &fl4);
+		if (IS_ERR(rt))
+			goto neigh;
+
+		if (rt->rt_type != RTN_UNICAST) {
+			ip_rt_put(rt);
+			goto neigh;
+		}
+		rt_dst_entry = &rt->dst;
+		break;
+	case AF_INET6:
+		rt_dst_entry = ipv6_stub->ipv6_dst_lookup_flow(
+			dev_net(netdev), NULL, &fl6, NULL);
+		if (IS_ERR(rt_dst_entry))
+			goto neigh;
+		break;
+	default:
+		return;
+	}
+
+	n = dst_neigh_lookup(rt_dst_entry, pkey);
+	if (!n) {
+		dst_release(rt_dst_entry);
+		goto neigh;
+	}
+
+	neigh_ha_snapshot(addr, n, netdev);
+	ether_addr_copy(dst, addr);
+	dst_release(rt_dst_entry);
+	neigh_release(n);
+	return;
+
+neigh:
 	n = neigh_lookup(&arp_tbl, pkey, netdev);
 	if (!n) {
 		n = neigh_create(&arp_tbl, pkey, netdev);
-- 
2.31.1

Re: [PATCH net-next V2 1/2] net/mlx5e: Support routed networks during IPsec MACs initialization

[Michal Swiatkowski]

On Tue, Jul 22, 2025 at 05:23:47PM +0300, Tariq Toukan wrote:
> From: Alexandre Cassen <acassen@corp.free.fr>
> 
> Remote IPsec tunnel endpoint may refer to a network segment that is
> not directly connected to the host. In such a case, IPsec tunnel
> endpoints are connected to a router and reachable via a routing path.
> In IPsec packet offload mode, HW is initialized with the MAC address
> of both IPsec tunnel endpoints.
> 
> Extend the current IPsec init MACs procedure to resolve nexthop for
> routed networks. Direct neighbour lookup and probe is still used
> for directly connected networks and as a fallback mechanism if fib
> lookup fails.
> 
> Signed-off-by: Alexandre Cassen <acassen@corp.free.fr>
> Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
> Reviewed-by: Cosmin Ratiu <cratiu@nvidia.com>
> Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
> ---
>  .../mellanox/mlx5/core/en_accel/ipsec.c       | 82 ++++++++++++++++++-
>  1 file changed, 80 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ipsec.c b/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ipsec.c
> index 77f61cd28a79..00e77c71e201 100644
> --- a/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ipsec.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ipsec.c
> @@ -36,6 +36,7 @@
>  #include <linux/inetdevice.h>
>  #include <linux/netdevice.h>
>  #include <net/netevent.h>
> +#include <net/ipv6_stubs.h>
>  
>  #include "en.h"
>  #include "eswitch.h"
> @@ -259,9 +260,15 @@ static void mlx5e_ipsec_init_macs(struct mlx5e_ipsec_sa_entry *sa_entry,
>  				  struct mlx5_accel_esp_xfrm_attrs *attrs)
>  {
>  	struct mlx5_core_dev *mdev = mlx5e_ipsec_sa2dev(sa_entry);
> +	struct mlx5e_ipsec_addr *addrs = &attrs->addrs;
>  	struct net_device *netdev = sa_entry->dev;
> +	struct xfrm_state *x = sa_entry->x;
> +	struct dst_entry *rt_dst_entry;
> +	struct flowi4 fl4 = {};
> +	struct flowi6 fl6 = {};
>  	struct neighbour *n;
>  	u8 addr[ETH_ALEN];
> +	struct rtable *rt;
>  	const void *pkey;
>  	u8 *dst, *src;
>  
> @@ -274,18 +281,89 @@ static void mlx5e_ipsec_init_macs(struct mlx5e_ipsec_sa_entry *sa_entry,
>  	case XFRM_DEV_OFFLOAD_IN:
>  		src = attrs->dmac;
>  		dst = attrs->smac;
> -		pkey = &attrs->addrs.saddr.a4;
> +
> +		switch (addrs->family) {
> +		case AF_INET:
> +			fl4.flowi4_proto = x->sel.proto;
> +			fl4.daddr = addrs->saddr.a4;
> +			fl4.saddr = addrs->daddr.a4;
> +			pkey = &addrs->saddr.a4;
> +			break;
> +		case AF_INET6:
> +			fl6.flowi6_proto = x->sel.proto;
> +			memcpy(fl6.daddr.s6_addr32, addrs->saddr.a6, 16);
> +			memcpy(fl6.saddr.s6_addr32, addrs->daddr.a6, 16);
> +			pkey = &addrs->saddr.a6;
> +			break;
> +		default:
> +			return;
> +		}
>  		break;
>  	case XFRM_DEV_OFFLOAD_OUT:
>  		src = attrs->smac;
>  		dst = attrs->dmac;
> -		pkey = &attrs->addrs.daddr.a4;

Isn't it worth to move getting pkey to separate function? The switch is
the same with OFFLOAD_IN and OFFLOAD_OUT.

> +		switch (addrs->family) {
> +		case AF_INET:
> +			fl4.flowi4_proto = x->sel.proto;
> +			fl4.daddr = addrs->daddr.a4;
> +			fl4.saddr = addrs->saddr.a4;
> +			pkey = &addrs->daddr.a4;
> +			break;
> +		case AF_INET6:
> +			fl6.flowi6_proto = x->sel.proto;
> +			memcpy(fl6.daddr.s6_addr32, addrs->daddr.a6, 16);
> +			memcpy(fl6.saddr.s6_addr32, addrs->saddr.a6, 16);
> +			pkey = &addrs->daddr.a6;
> +			break;
> +		default:
> +			return;
> +		}
>  		break;
>  	default:
>  		return;
>  	}
>  
>  	ether_addr_copy(src, addr);
> +
> +	/* Destination can refer to a routed network, so perform FIB lookup
> +	 * to resolve nexthop and get its MAC. Neighbour resolution is used as
> +	 * fallback.
> +	 */
> +	switch (addrs->family) {
> +	case AF_INET:
> +		rt = ip_route_output_key(dev_net(netdev), &fl4);
> +		if (IS_ERR(rt))
> +			goto neigh;
> +
> +		if (rt->rt_type != RTN_UNICAST) {
> +			ip_rt_put(rt);
> +			goto neigh;
> +		}
> +		rt_dst_entry = &rt->dst;
> +		break;
> +	case AF_INET6:
> +		rt_dst_entry = ipv6_stub->ipv6_dst_lookup_flow(
> +			dev_net(netdev), NULL, &fl6, NULL);
> +		if (IS_ERR(rt_dst_entry))
> +			goto neigh;
> +		break;
> +	default:
> +		return;
> +	}
> +
> +	n = dst_neigh_lookup(rt_dst_entry, pkey);
> +	if (!n) {
> +		dst_release(rt_dst_entry);
> +		goto neigh;
> +	}
> +
> +	neigh_ha_snapshot(addr, n, netdev);
> +	ether_addr_copy(dst, addr);
> +	dst_release(rt_dst_entry);
> +	neigh_release(n);
> +	return;
> +
> +neigh:
>  	n = neigh_lookup(&arp_tbl, pkey, netdev);
>  	if (!n) {
>  		n = neigh_create(&arp_tbl, pkey, netdev);

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

> -- 
> 2.31.1

Re: [PATCH net-next V2 1/2] net/mlx5e: Support routed networks during IPsec MACs initialization

[Leon Romanovsky]

On Wed, Jul 23, 2025 at 08:52:09AM +0200, Michal Swiatkowski wrote:
> On Tue, Jul 22, 2025 at 05:23:47PM +0300, Tariq Toukan wrote:
> > From: Alexandre Cassen <acassen@corp.free.fr>
> > 
> > Remote IPsec tunnel endpoint may refer to a network segment that is
> > not directly connected to the host. In such a case, IPsec tunnel
> > endpoints are connected to a router and reachable via a routing path.
> > In IPsec packet offload mode, HW is initialized with the MAC address
> > of both IPsec tunnel endpoints.
> > 
> > Extend the current IPsec init MACs procedure to resolve nexthop for
> > routed networks. Direct neighbour lookup and probe is still used
> > for directly connected networks and as a fallback mechanism if fib
> > lookup fails.
> > 
> > Signed-off-by: Alexandre Cassen <acassen@corp.free.fr>
> > Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
> > Reviewed-by: Cosmin Ratiu <cratiu@nvidia.com>
> > Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
> > ---
> >  .../mellanox/mlx5/core/en_accel/ipsec.c       | 82 ++++++++++++++++++-
> >  1 file changed, 80 insertions(+), 2 deletions(-)

<...>

> > @@ -274,18 +281,89 @@ static void mlx5e_ipsec_init_macs(struct mlx5e_ipsec_sa_entry *sa_entry,
> >  	case XFRM_DEV_OFFLOAD_IN:
> >  		src = attrs->dmac;
> >  		dst = attrs->smac;
> > -		pkey = &attrs->addrs.saddr.a4;
> > +
> > +		switch (addrs->family) {
> > +		case AF_INET:
> > +			fl4.flowi4_proto = x->sel.proto;
> > +			fl4.daddr = addrs->saddr.a4;
> > +			fl4.saddr = addrs->daddr.a4;
> > +			pkey = &addrs->saddr.a4;
> > +			break;
> > +		case AF_INET6:
> > +			fl6.flowi6_proto = x->sel.proto;
> > +			memcpy(fl6.daddr.s6_addr32, addrs->saddr.a6, 16);
> > +			memcpy(fl6.saddr.s6_addr32, addrs->daddr.a6, 16);
> > +			pkey = &addrs->saddr.a6;
> > +			break;
> > +		default:
> > +			return;
> > +		}
> >  		break;
> >  	case XFRM_DEV_OFFLOAD_OUT:
> >  		src = attrs->smac;
> >  		dst = attrs->dmac;
> > -		pkey = &attrs->addrs.daddr.a4;
> 
> Isn't it worth to move getting pkey to separate function? The switch is
> the same with OFFLOAD_IN and OFFLOAD_OUT.

The content of the switch is completely opposite, as an example for pkey:
In OFFLOAD_IN:
pkey = &addrs->...S...addr.a4;
pkey = &addrs->...S...addr.a6;

In OFFLOAD_OUT:
pkey = &addrs->...D...addr.a4;
pkey = &addrs->...D...addr.a6;

There is only one line which is common: "... = x->sel.proto;"

> 
> > +		switch (addrs->family) {
> > +		case AF_INET:
> > +			fl4.flowi4_proto = x->sel.proto;
> > +			fl4.daddr = addrs->daddr.a4;
> > +			fl4.saddr = addrs->saddr.a4;
> > +			pkey = &addrs->daddr.a4;
> > +			break;
> > +		case AF_INET6:
> > +			fl6.flowi6_proto = x->sel.proto;
> > +			memcpy(fl6.daddr.s6_addr32, addrs->daddr.a6, 16);
> > +			memcpy(fl6.saddr.s6_addr32, addrs->saddr.a6, 16);
> > +			pkey = &addrs->daddr.a6;
> > +			break;
> > +		default:
> > +			return;

<...>

> >  	n = neigh_lookup(&arp_tbl, pkey, netdev);
> >  	if (!n) {
> >  		n = neigh_create(&arp_tbl, pkey, netdev);
> 
> Code looks fine,
> Reviewed-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com>

Thanks

> 
> > -- 
> > 2.31.1
> 

[PATCH net-next V2 2/2] net/mlx5e: Expose TIS via devlink tx reporter diagnose

[Tariq Toukan]

From: Feng Liu <feliu@nvidia.com>

Underneath "TIS Config" tag expose TIS diagnostic information.
Expose the tisn of each TC under each lag port.

$ sudo devlink health diagnose auxiliary/mlx5_core.eth.2/131072 reporter tx
......
  TIS Config:
      lag port: 0 tc: 0 tisn: 0
      lag port: 1 tc: 0 tisn: 8
......

Signed-off-by: Feng Liu <feliu@nvidia.com>
Reviewed-by: Aya Levin <ayal@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
---
 .../mellanox/mlx5/core/en/reporter_tx.c       | 25 +++++++++++++++++++
 1 file changed, 25 insertions(+)

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 bd96988e102c..85d5cb39b107 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en/reporter_tx.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en/reporter_tx.c
@@ -311,6 +311,30 @@ mlx5e_tx_reporter_diagnose_common_config(struct devlink_health_reporter *reporte
 	mlx5e_health_fmsg_named_obj_nest_end(fmsg);
 }
 
+static void
+mlx5e_tx_reporter_diagnose_tis_config(struct devlink_health_reporter *reporter,
+				      struct devlink_fmsg *fmsg)
+{
+	struct mlx5e_priv *priv = devlink_health_reporter_priv(reporter);
+	u8 num_tc = mlx5e_get_dcb_num_tc(&priv->channels.params);
+	u32 tc, i, tisn;
+
+	devlink_fmsg_arr_pair_nest_start(fmsg, "TIS Config");
+	for (i = 0; i < mlx5e_get_num_lag_ports(priv->mdev); i++) {
+		for (tc = 0; tc < num_tc; tc++) {
+			tisn = mlx5e_profile_get_tisn(priv->mdev, priv,
+						      priv->profile, i, tc);
+
+			devlink_fmsg_obj_nest_start(fmsg);
+			devlink_fmsg_u32_pair_put(fmsg, "lag port", i);
+			devlink_fmsg_u32_pair_put(fmsg, "tc", tc);
+			devlink_fmsg_u32_pair_put(fmsg, "tisn", tisn);
+			devlink_fmsg_obj_nest_end(fmsg);
+		}
+	}
+	devlink_fmsg_arr_pair_nest_end(fmsg);
+}
+
 static int mlx5e_tx_reporter_diagnose(struct devlink_health_reporter *reporter,
 				      struct devlink_fmsg *fmsg,
 				      struct netlink_ext_ack *extack)
@@ -326,6 +350,7 @@ static int mlx5e_tx_reporter_diagnose(struct devlink_health_reporter *reporter,
 		goto unlock;
 
 	mlx5e_tx_reporter_diagnose_common_config(reporter, fmsg);
+	mlx5e_tx_reporter_diagnose_tis_config(reporter, fmsg);
 	devlink_fmsg_arr_pair_nest_start(fmsg, "SQs");
 
 	for (i = 0; i < priv->channels.num; i++) {
-- 
2.31.1

Re: [PATCH net-next V2 2/2] net/mlx5e: Expose TIS via devlink tx reporter diagnose

[Michal Swiatkowski]

On Tue, Jul 22, 2025 at 05:23:48PM +0300, Tariq Toukan wrote:
> From: Feng Liu <feliu@nvidia.com>
> 
> Underneath "TIS Config" tag expose TIS diagnostic information.
> Expose the tisn of each TC under each lag port.
> 
> $ sudo devlink health diagnose auxiliary/mlx5_core.eth.2/131072 reporter tx
> ......
>   TIS Config:
>       lag port: 0 tc: 0 tisn: 0
>       lag port: 1 tc: 0 tisn: 8
> ......
> 
> Signed-off-by: Feng Liu <feliu@nvidia.com>
> Reviewed-by: Aya Levin <ayal@nvidia.com>
> Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
> ---
>  .../mellanox/mlx5/core/en/reporter_tx.c       | 25 +++++++++++++++++++
>  1 file changed, 25 insertions(+)
> 
> 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 bd96988e102c..85d5cb39b107 100644
> --- a/drivers/net/ethernet/mellanox/mlx5/core/en/reporter_tx.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/en/reporter_tx.c
> @@ -311,6 +311,30 @@ mlx5e_tx_reporter_diagnose_common_config(struct devlink_health_reporter *reporte
>  	mlx5e_health_fmsg_named_obj_nest_end(fmsg);
>  }
>  
> +static void
> +mlx5e_tx_reporter_diagnose_tis_config(struct devlink_health_reporter *reporter,
> +				      struct devlink_fmsg *fmsg)
> +{
> +	struct mlx5e_priv *priv = devlink_health_reporter_priv(reporter);
> +	u8 num_tc = mlx5e_get_dcb_num_tc(&priv->channels.params);
> +	u32 tc, i, tisn;
> +
> +	devlink_fmsg_arr_pair_nest_start(fmsg, "TIS Config");
> +	for (i = 0; i < mlx5e_get_num_lag_ports(priv->mdev); i++) {
> +		for (tc = 0; tc < num_tc; tc++) {

nit: tisn can be defined in this for, not outside.

> +			tisn = mlx5e_profile_get_tisn(priv->mdev, priv,
> +						      priv->profile, i, tc);
> +
> +			devlink_fmsg_obj_nest_start(fmsg);
> +			devlink_fmsg_u32_pair_put(fmsg, "lag port", i);
> +			devlink_fmsg_u32_pair_put(fmsg, "tc", tc);
> +			devlink_fmsg_u32_pair_put(fmsg, "tisn", tisn);
> +			devlink_fmsg_obj_nest_end(fmsg);
> +		}
> +	}
> +	devlink_fmsg_arr_pair_nest_end(fmsg);
> +}
> +
>  static int mlx5e_tx_reporter_diagnose(struct devlink_health_reporter *reporter,
>  				      struct devlink_fmsg *fmsg,
>  				      struct netlink_ext_ack *extack)
> @@ -326,6 +350,7 @@ static int mlx5e_tx_reporter_diagnose(struct devlink_health_reporter *reporter,
>  		goto unlock;
>  
>  	mlx5e_tx_reporter_diagnose_common_config(reporter, fmsg);
> +	mlx5e_tx_reporter_diagnose_tis_config(reporter, fmsg);
>  	devlink_fmsg_arr_pair_nest_start(fmsg, "SQs");
>  	for (i = 0; i < priv->channels.num; i++) {

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

> -- 
> 2.31.1

Re: [PATCH net-next V2 0/2] net/mlx5e: misc changes 2025-07-22

[patchwork-bot+netdevbpf]

Hello:

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

On Tue, 22 Jul 2025 17:23:46 +0300 you wrote:
> Hi,
> 
> This series contains misc enhancements to the mlx5e driver.
> This is V2. Previous one was deferred, find it here:
> https://lore.kernel.org/all/1752771792-265762-1-git-send-email-tariqt@nvidia.com/
> 
> Regards,
> Tariq
> 
> [...]

Here is the summary with links:
  - [net-next,V2,1/2] net/mlx5e: Support routed networks during IPsec MACs initialization
    https://git.kernel.org/netdev/net-next/c/71670f766b8f
  - [net-next,V2,2/2] net/mlx5e: Expose TIS via devlink tx reporter diagnose
    https://git.kernel.org/netdev/net-next/c/5474ca211819

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