[PATCH net-next] net/mlx5e: Modify mlx5e_xdp_xmit sq selection

[PATCH net-next] net/mlx5e: Modify mlx5e_xdp_xmit sq selection

[Zijian Zhang]

From: Zijian Zhang <zijianzhang@bytedance.com>

When performing XDP_REDIRECT from one mlnx device to another, using
smp_processor_id() to select the queue may go out-of-range.

Assume eth0 is redirecting a packet to eth1, eth1 is configured
with only 8 channels, while eth0 has its RX queues pinned to
higher-numbered CPUs (e.g. CPU 12). When a packet is received on
such a CPU and redirected to eth1, the driver uses smp_processor_id()
as the SQ index. Since the CPU ID is larger than the number of queues
on eth1, the lookup (priv->channels.c[sq_num]) goes out of range and
the redirect fails.

This patch fixes the issue by mapping the CPU ID to a valid channel
index using modulo arithmetic:

     sq_num = smp_processor_id() % priv->channels.num;

With this change, XDP_REDIRECT works correctly even when the source
device uses high CPU affinities and the target device has fewer TX
queues.

Signed-off-by: Zijian Zhang <zijianzhang@bytedance.com>
---
  drivers/net/ethernet/mellanox/mlx5/core/en/xdp.c | 6 +-----
  1 file changed, 1 insertion(+), 5 deletions(-)

diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en/xdp.c 
b/drivers/net/ethernet/mellanox/mlx5/core/en/xdp.c
index 5d51600935a6..61394257c65f 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en/xdp.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en/xdp.c
@@ -855,11 +855,7 @@ int mlx5e_xdp_xmit(struct net_device *dev, int n, 
struct xdp_frame **frames,
  	if (unlikely(flags & ~XDP_XMIT_FLAGS_MASK))
  		return -EINVAL;

-	sq_num = smp_processor_id();
-
-	if (unlikely(sq_num >= priv->channels.num))
-		return -ENXIO;
-
+	sq_num = smp_processor_id() % priv->channels.num;
  	sq = priv->channels.c[sq_num]->xdpsq;

  	for (i = 0; i < n; i++) {
-- 
2.20.1

Re: [PATCH net-next] net/mlx5e: Modify mlx5e_xdp_xmit sq selection

[Hariprasad Kelam]

On 2025-10-31 at 06:12:50, Zijian Zhang (zijianzhang@bytedance.com) wrote:
> From: Zijian Zhang <zijianzhang@bytedance.com>
> 
> When performing XDP_REDIRECT from one mlnx device to another, using
> smp_processor_id() to select the queue may go out-of-range.
> 
> Assume eth0 is redirecting a packet to eth1, eth1 is configured
> with only 8 channels, while eth0 has its RX queues pinned to
> higher-numbered CPUs (e.g. CPU 12). When a packet is received on
> such a CPU and redirected to eth1, the driver uses smp_processor_id()
> as the SQ index. Since the CPU ID is larger than the number of queues
> on eth1, the lookup (priv->channels.c[sq_num]) goes out of range and
> the redirect fails.
> 
> This patch fixes the issue by mapping the CPU ID to a valid channel
> index using modulo arithmetic:
> 
>     sq_num = smp_processor_id() % priv->channels.num;
> 
> With this change, XDP_REDIRECT works correctly even when the source
> device uses high CPU affinities and the target device has fewer TX
> queues.
> 
> Signed-off-by: Zijian Zhang <zijianzhang@bytedance.com>
> ---
>  drivers/net/ethernet/mellanox/mlx5/core/en/xdp.c | 6 +-----
>  1 file changed, 1 insertion(+), 5 deletions(-)
> 
> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en/xdp.c
> b/drivers/net/ethernet/mellanox/mlx5/core/en/xdp.c
> index 5d51600935a6..61394257c65f 100644
> --- a/drivers/net/ethernet/mellanox/mlx5/core/en/xdp.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/en/xdp.c
> @@ -855,11 +855,7 @@ int mlx5e_xdp_xmit(struct net_device *dev, int n,
> struct xdp_frame **frames,
>  	if (unlikely(flags & ~XDP_XMIT_FLAGS_MASK))
>  		return -EINVAL;
> 
> -	sq_num = smp_processor_id();
> -
> -	if (unlikely(sq_num >= priv->channels.num))
> -		return -ENXIO;
> -
> +	sq_num = smp_processor_id() % priv->channels.num;
>  	sq = priv->channels.c[sq_num]->xdpsq;
> 
>  	for (i = 0; i < n; i++) {
 
Reviewed-by: Hariprasad Kelam <hkelam@marvell.com> 

Re: [PATCH net-next] net/mlx5e: Modify mlx5e_xdp_xmit sq selection

[Jakub Kicinski]

On Thu, 30 Oct 2025 17:42:50 -0700 Zijian Zhang wrote:
> When performing XDP_REDIRECT from one mlnx device to another, using
> smp_processor_id() to select the queue may go out-of-range.
> 
> Assume eth0 is redirecting a packet to eth1, eth1 is configured
> with only 8 channels, while eth0 has its RX queues pinned to
> higher-numbered CPUs (e.g. CPU 12). When a packet is received on
> such a CPU and redirected to eth1, the driver uses smp_processor_id()
> as the SQ index. Since the CPU ID is larger than the number of queues
> on eth1, the lookup (priv->channels.c[sq_num]) goes out of range and
> the redirect fails.
> 
> This patch fixes the issue by mapping the CPU ID to a valid channel
> index using modulo arithmetic:
> 
>      sq_num = smp_processor_id() % priv->channels.num;
> 
> With this change, XDP_REDIRECT works correctly even when the source
> device uses high CPU affinities and the target device has fewer TX
> queues.

And what if you have 8 queues and CPUs 0 and 8 try to Xmit at the same
time? Is there any locking here?
-- 
pw-bot: cr

Re: [PATCH net-next] net/mlx5e: Modify mlx5e_xdp_xmit sq selection

[Zijian Zhang]

On 10/31/25 11:40 AM, Jakub Kicinski wrote:
> On Thu, 30 Oct 2025 17:42:50 -0700 Zijian Zhang wrote:
>> When performing XDP_REDIRECT from one mlnx device to another, using
>> smp_processor_id() to select the queue may go out-of-range.
>>
>> Assume eth0 is redirecting a packet to eth1, eth1 is configured
>> with only 8 channels, while eth0 has its RX queues pinned to
>> higher-numbered CPUs (e.g. CPU 12). When a packet is received on
>> such a CPU and redirected to eth1, the driver uses smp_processor_id()
>> as the SQ index. Since the CPU ID is larger than the number of queues
>> on eth1, the lookup (priv->channels.c[sq_num]) goes out of range and
>> the redirect fails.
>>
>> This patch fixes the issue by mapping the CPU ID to a valid channel
>> index using modulo arithmetic:
>>
>>       sq_num = smp_processor_id() % priv->channels.num;
>>
>> With this change, XDP_REDIRECT works correctly even when the source
>> device uses high CPU affinities and the target device has fewer TX
>> queues.
> 
> And what if you have 8 queues and CPUs 0 and 8 try to Xmit at the same
> time? Is there any locking here?

Thanks for pointing this out, I will add a lock here.