Re: [dpdk-dev] [dpdk-stable] [PATCH v4 1/3] net/mlx5: add a devarg to specify MPRQ stride size

[Luca Boccassi <bluca@debian.org>]

On Wed, 2020-04-15 at 15:34 +0000, Alexander Kozyrev wrote:
> On Wed, April 15, 2020 7:26 Luca Boccassi wrote:
> > On Wed, 2020-04-15 at 12:01 +0100, Ferruh Yigit wrote:
> > > On 4/14/2020 1:52 PM, Thomas Monjalon wrote:
> > > > 14/04/2020 13:42, Ferruh Yigit:
> > > > > On 4/9/2020 11:23 PM, Alexander Kozyrev wrote:
> > > > > > Define a device parameter to configure log 2 of a stride size
> > > > > > for MPRQ
> > > > > > - mprq_log_stride_size. User is able to specify a stride size in
> > > > > > a range allowed by an underlying hardware. The default stride
> > > > > > size is defined as
> > > > > > 2048 bytes to encompass most commonly used packet sizes in the
> > > > > > Internet (MTU 1518 and less) and will be used in case a maximum
> > > > > > configured packet size cannot fit into the largest possible
> > > > > > stride size. Otherwise a stride size is set to a large enough value to
> > encompass a whole packet.
> > > > > > Cc: stable@dpdk.org
> > > > > 
> > > > > Hi Alexander,
> > > > > 
> > > > > This is a new feature, and you are asking it for to be backported
> > > > > to the stable trees.
> > > > > 
> > > > > There is no question on getting the fixes to the stable tree, but
> > > > > for backporting features I would like to get the comment of the
> > > > > stable tree maintainers first before merging the series.
> > > > 
> > > > As far as I know, there is a fix hidden in this series, for the case
> > > > of jumbo frames.
> > > > In my understanding, jumbo frames cannot be fixed without a new option.
> > > > I agree it's tricky deciding what is the limit with backports.
> > > > 
> > > 
> > > I missed the fix bit, so if there is no objection from stable tree
> > > maintainers I will continue with the set keeping the stable tag.
> > 
> > Given it's confined to a single PMD it's fine by me, provided that:
> > 
> > 1) Backward compatibility is maintained
> > 2) Forward compatibility is maintained (eg: going 19.11.x to 20.02 should still
> > work and not cause any errors)
> 
> The whole point of these patches are to fix the inability to handle 9K jumbo frames.
> A new devarg is required in order not to break the backward compatibility.
> So I do not expect any issues with backward/forward compatibility with these patches.
> One thing I need to mention: backporting requires one small change.
> Conversion from MLX5_ASSERT to assert clauses since we reworked them in 20.02.
> I can provide a separate list of patches for 19.11 with this change if it works better for you.
> Thank you for you assistance and let me know how we should proceed further.

Ok, thanks. It's not necessary to send a series if the only change is
the assert, I can fix it myself when backporting.