[v4,1/3] net/mlx5: add a devarg to specify MPRQ stride size

  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

Signed-off-by: Alexander Kozyrev <akozyrev@mellanox.com>
Acked-by: Viacheslav Ovsiienko <viacheslavo@mellanox.com>
---
 doc/guides/nics/mlx5.rst               | 17 +++++++++--
 doc/guides/rel_notes/release_20_05.rst |  1 +
 drivers/net/mlx5/mlx5.c                | 34 +++++++++++++++++-----
 drivers/net/mlx5/mlx5.h                |  1 +
 drivers/net/mlx5/mlx5_defs.h           |  3 ++
 drivers/net/mlx5/mlx5_rxq.c            | 52 +++++++++++++++++++++++++---------
 6 files changed, 85 insertions(+), 23 deletions(-)
  

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.

Or if the stable tag added by mistake please let me know, I can remove them
while merging.

Thanks,
ferruh

> 
> Signed-off-by: Alexander Kozyrev <akozyrev@mellanox.com>
> Acked-by: Viacheslav Ovsiienko <viacheslavo@mellanox.com>

<...>
  

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.
  

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.
  

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)
  

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.
  

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.