mbox series

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

Message ID 20230614090006.594909-1-maxtram95@gmail.com (mailing list archive)
Headers show
Series xdp_rxq_info_reg fixes for mlx5e | expand

Message

Maxim Mikityanskiy June 14, 2023, 9 a.m. UTC
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(-)

Comments

Jakub Kicinski June 16, 2023, 5:32 a.m. UTC | #1
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.
Saeed Mahameed June 16, 2023, 6:54 p.m. UTC | #2
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
Jakub Kicinski June 16, 2023, 7:23 p.m. UTC | #3
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.
Maxim Mikityanskiy June 16, 2023, 7:33 p.m. UTC | #4
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/