[PATCH net-next v4 0/2] xdp_rxq_info_reg fixes for mlx5e

[PATCH net-next v4 0/2] xdp_rxq_info_reg fixes for mlx5e

[Maxim Mikityanskiy]

Resending the patches, as I'm afraid they were lost eventually:

https://lore.kernel.org/all/ZDFPCxBz0u6ClXnQ@mail.gmail.com/

Marked for net-next, as I'm not sure what the consensus was, but they
can be applied cleanly to net as well.

--

Two small fixes that add parameters to xdp_rxq_info_reg missed in older
commits.

v2 changes:

Let en/params.c decide the right size for xdp_frag_size, rather than
make en_main.c aware of the implementation details.

v3 changes:

Set xdp_frag_size in all successful flows of mlx5e_build_rq_frags_info.

v4 changes:

No changes, rebased over the latest net-next.

Maxim Mikityanskiy (2):
  net/mlx5e: XDP, Allow growing tail for XDP multi buffer
  net/mlx5e: xsk: Set napi_id to support busy polling on XSK RQ

 drivers/net/ethernet/mellanox/mlx5/core/en/params.c    | 8 ++++++--
 drivers/net/ethernet/mellanox/mlx5/core/en/params.h    | 1 +
 drivers/net/ethernet/mellanox/mlx5/core/en/xsk/setup.c | 2 +-
 drivers/net/ethernet/mellanox/mlx5/core/en_main.c      | 7 ++++---
 4 files changed, 12 insertions(+), 6 deletions(-)

-- 
2.41.0

[PATCH net-next v4 1/2] net/mlx5e: XDP, Allow growing tail for XDP multi buffer

[Maxim Mikityanskiy]

The cited commits missed passing frag_size to __xdp_rxq_info_reg, which
is required by bpf_xdp_adjust_tail to support growing the tail pointer
in fragmented packets. Pass the missing parameter when the current RQ
mode allows XDP multi buffer.

Fixes: ea5d49bdae8b ("net/mlx5e: Add XDP multi buffer support to the non-linear legacy RQ")
Fixes: 9cb9482ef10e ("net/mlx5e: Use fragments of the same size in non-linear legacy RQ with XDP")
Signed-off-by: Maxim Mikityanskiy <maxtram95@gmail.com>
Cc: Tariq Toukan <tariqt@nvidia.com>
Reviewed-by: Tariq Toukan <tariqt@nvidia.com>
---
 drivers/net/ethernet/mellanox/mlx5/core/en/params.c | 8 ++++++--
 drivers/net/ethernet/mellanox/mlx5/core/en/params.h | 1 +
 drivers/net/ethernet/mellanox/mlx5/core/en_main.c   | 7 ++++---
 3 files changed, 11 insertions(+), 5 deletions(-)

diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en/params.c b/drivers/net/ethernet/mellanox/mlx5/core/en/params.c
index 9c94807097cb..5ce28ff7685f 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en/params.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en/params.c
@@ -732,7 +732,8 @@ static void mlx5e_rx_compute_wqe_bulk_params(struct mlx5e_params *params,
 static int mlx5e_build_rq_frags_info(struct mlx5_core_dev *mdev,
 				     struct mlx5e_params *params,
 				     struct mlx5e_xsk_param *xsk,
-				     struct mlx5e_rq_frags_info *info)
+				     struct mlx5e_rq_frags_info *info,
+				     u32 *xdp_frag_size)
 {
 	u32 byte_count = MLX5E_SW2HW_MTU(params, params->sw_mtu);
 	int frag_size_max = DEFAULT_FRAG_SIZE;
@@ -845,6 +846,8 @@ static int mlx5e_build_rq_frags_info(struct mlx5_core_dev *mdev,
 
 	info->log_num_frags = order_base_2(info->num_frags);
 
+	*xdp_frag_size = info->num_frags > 1 && params->xdp_prog ? PAGE_SIZE : 0;
+
 	return 0;
 }
 
@@ -989,7 +992,8 @@ int mlx5e_build_rq_param(struct mlx5_core_dev *mdev,
 	}
 	default: /* MLX5_WQ_TYPE_CYCLIC */
 		MLX5_SET(wq, wq, log_wq_sz, params->log_rq_mtu_frames);
-		err = mlx5e_build_rq_frags_info(mdev, params, xsk, &param->frags_info);
+		err = mlx5e_build_rq_frags_info(mdev, params, xsk, &param->frags_info,
+						&param->xdp_frag_size);
 		if (err)
 			return err;
 		ndsegs = param->frags_info.num_frags;
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en/params.h b/drivers/net/ethernet/mellanox/mlx5/core/en/params.h
index a5d20f6d6d9c..6800949dafbc 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en/params.h
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en/params.h
@@ -24,6 +24,7 @@ struct mlx5e_rq_param {
 	u32                        rqc[MLX5_ST_SZ_DW(rqc)];
 	struct mlx5_wq_param       wq;
 	struct mlx5e_rq_frags_info frags_info;
+	u32                        xdp_frag_size;
 };
 
 struct mlx5e_sq_param {
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
index a7c526ee5024..a5bdf78955d7 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
@@ -641,7 +641,7 @@ static void mlx5e_free_mpwqe_rq_drop_page(struct mlx5e_rq *rq)
 }
 
 static int mlx5e_init_rxq_rq(struct mlx5e_channel *c, struct mlx5e_params *params,
-			     struct mlx5e_rq *rq)
+			     u32 xdp_frag_size, struct mlx5e_rq *rq)
 {
 	struct mlx5_core_dev *mdev = c->mdev;
 	int err;
@@ -665,7 +665,8 @@ static int mlx5e_init_rxq_rq(struct mlx5e_channel *c, struct mlx5e_params *param
 	if (err)
 		return err;
 
-	return xdp_rxq_info_reg(&rq->xdp_rxq, rq->netdev, rq->ix, c->napi.napi_id);
+	return __xdp_rxq_info_reg(&rq->xdp_rxq, rq->netdev, rq->ix, c->napi.napi_id,
+				  xdp_frag_size);
 }
 
 static int mlx5_rq_shampo_alloc(struct mlx5_core_dev *mdev,
@@ -2240,7 +2241,7 @@ static int mlx5e_open_rxq_rq(struct mlx5e_channel *c, struct mlx5e_params *param
 {
 	int err;
 
-	err = mlx5e_init_rxq_rq(c, params, &c->rq);
+	err = mlx5e_init_rxq_rq(c, params, rq_params->xdp_frag_size, &c->rq);
 	if (err)
 		return err;
 
-- 
2.41.0

[PATCH net-next v4 2/2] net/mlx5e: xsk: Set napi_id to support busy polling on XSK RQ

[Maxim Mikityanskiy]

The cited commit missed setting napi_id on XSK RQs, it only affected
regular RQs. Add the missing part to support socket busy polling on XSK
RQs.

Fixes: a2740f529da2 ("net/mlx5e: xsk: Set napi_id to support busy polling")
Signed-off-by: Maxim Mikityanskiy <maxtram95@gmail.com>
Reviewed-by: Tariq Toukan <tariqt@nvidia.com>
---
 drivers/net/ethernet/mellanox/mlx5/core/en/xsk/setup.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en/xsk/setup.c b/drivers/net/ethernet/mellanox/mlx5/core/en/xsk/setup.c
index ed279f450976..36826b582484 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en/xsk/setup.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en/xsk/setup.c
@@ -86,7 +86,7 @@ static int mlx5e_init_xsk_rq(struct mlx5e_channel *c,
 	if (err)
 		return err;
 
-	return  xdp_rxq_info_reg(&rq->xdp_rxq, rq->netdev, rq_xdp_ix, 0);
+	return xdp_rxq_info_reg(&rq->xdp_rxq, rq->netdev, rq_xdp_ix, c->napi.napi_id);
 }
 
 static int mlx5e_open_xsk_rq(struct mlx5e_channel *c, struct mlx5e_params *params,
-- 
2.41.0

Re: [PATCH net-next v4 0/2] xdp_rxq_info_reg fixes for mlx5e

[Jakub Kicinski]

On Wed, 14 Jun 2023 12:00:04 +0300 Maxim Mikityanskiy wrote:
> Marked for net-next, as I'm not sure what the consensus was, but they
> can be applied cleanly to net as well.

Sorry for lack of clarity, you should drop the fixes tags.
If not implementing something was a bug most of the patches we merge
would have a fixes tag. That devalues the Fixes tag completely.
You can still ask Greg/Sasha to backport it later if you want.

Re: [PATCH net-next v4 0/2] xdp_rxq_info_reg fixes for mlx5e

[Saeed Mahameed]

On 15 Jun 22:32, Jakub Kicinski wrote:
>On Wed, 14 Jun 2023 12:00:04 +0300 Maxim Mikityanskiy wrote:
>> Marked for net-next, as I'm not sure what the consensus was, but they
>> can be applied cleanly to net as well.
>
>Sorry for lack of clarity, you should drop the fixes tags.
>If not implementing something was a bug most of the patches we merge
>would have a fixes tag. That devalues the Fixes tag completely.
>You can still ask Greg/Sasha to backport it later if you want.
>

You don't think this should go to net ? 

The first 3 version were targeting net branch .. I don't know why Maxim
decided to switch v4 to net-next, Maybe I missed an email ? 

IMHO, I think these are net worthy since they are fixing 
issues with blabla, for commits claiming to add support for blabla.

I already applied those earlier to my net queue and was working on
submission today, let me know if you are ok for me to send those two
patches in my today's net PR.

Thanks,
Saeed

Re: [PATCH net-next v4 0/2] xdp_rxq_info_reg fixes for mlx5e

[Jakub Kicinski]

On Fri, 16 Jun 2023 11:54:21 -0700 Saeed Mahameed wrote:
> On 15 Jun 22:32, Jakub Kicinski wrote:
> >On Wed, 14 Jun 2023 12:00:04 +0300 Maxim Mikityanskiy wrote:  
> >> Marked for net-next, as I'm not sure what the consensus was, but they
> >> can be applied cleanly to net as well.  
> >
> >Sorry for lack of clarity, you should drop the fixes tags.
> >If not implementing something was a bug most of the patches we merge
> >would have a fixes tag. That devalues the Fixes tag completely.
> >You can still ask Greg/Sasha to backport it later if you want.
> 
> You don't think this should go to net ? 
> 
> The first 3 version were targeting net branch .. I don't know why Maxim
> decided to switch v4 to net-next, Maybe I missed an email ? 
> 
> IMHO, I think these are net worthy since they are fixing 
> issues with blabla, for commits claiming to add support for blabla.
> 
> I already applied those earlier to my net queue and was working on
> submission today, let me know if you are ok for me to send those two
> patches in my today's net PR.

If you already have them queued up for net, that's fine.

Re: [PATCH net-next v4 0/2] xdp_rxq_info_reg fixes for mlx5e

[Maxim Mikityanskiy]

On Fri, 16 Jun 2023 at 11:54:21 -0700, Saeed Mahameed wrote:
> On 15 Jun 22:32, Jakub Kicinski wrote:
> > On Wed, 14 Jun 2023 12:00:04 +0300 Maxim Mikityanskiy wrote:
> > > Marked for net-next, as I'm not sure what the consensus was, but they
> > > can be applied cleanly to net as well.
> > 
> > Sorry for lack of clarity, you should drop the fixes tags.
> > If not implementing something was a bug most of the patches we merge
> > would have a fixes tag. That devalues the Fixes tag completely.
> > You can still ask Greg/Sasha to backport it later if you want.
> > 
> 
> You don't think this should go to net ?
> 
> The first 3 version were targeting net branch .. I don't know why Maxim
> decided to switch v4 to net-next, Maybe I missed an email ?
> 
> IMHO, I think these are net worthy since they are fixing issues with blabla,
> for commits claiming to add support for blabla.

I agree it's worth applying them to net, and I think it's a valid use
case for "Fixes" when the original commit says "implement X" but doesn't
implement X.

> I already applied those earlier to my net queue and was working on
> submission today, let me know if you are ok for me to send those two
> patches in my today's net PR.

If you were going to send these via net, that would be the best, please
go ahead and ignore my v4. I resent it solely because there was no
activity since February, and no one replied my ping two months ago [1].
Sorry for the noise.

Thanks,
Max

[1]: https://lore.kernel.org/all/ZDFPCxBz0u6ClXnQ@mail.gmail.com/