Hi Ferruh
Thanks for the review.
Please see inside some clarifications.
From: Ferruh Yigit
> On 12/8/2021 12:52 PM, Michael Baum wrote:
> >
> > On 12/07/2021 3:41 PM, ferruh.yi...@intel.com wrote:
> >>
> >> On 11/23/2021 6:38 PM, michae...@nvidia.com wrote:
> >>> From: Michael Baum<michae...@nvidia.com>
> >>>
> >>> In Multy-Packet RQ creation, the user can choose the number of
> >>> strides
> >>
> >> Multi-Packet ?
> >
> > Yes, you're right. It should have been Multi-Packet, thank you for that.
> >
> >>
> >>> and their size in bytes. The user updates it using specific devargs
> >>> for both of these parameters.
> >>> The above two parameters determine the size of the WQE which is
> >>> actually their product of multiplication.
> >>>
> >>> If the user selects values that are not in the supported range, the
> >>> PMD changes them to default values. However, apart from the range
> >>> limitations for each parameter individually there is also a minimum
> >>> value on their multiplication. When the user selects values that
> >>> their multiplication are lower than minimum value, no adjustment is
> >>> made and the creation of the WQE fails.
> >>>> This patch adds an adjustment in these cases as well. When the user
> >>> selects values whose multiplication is lower than the minimum, they
> >>> are replaced with the default values.
> >>>
> >>> Fixes: ecb160456aed ("net/mlx5: add device parameter for MPRQ stride
> >>> size") Cc:sta...@dpdk.org
> >>>
> >>
> >> Again, not sure if we can backport this patch, this looks a behavior
> >> change more than a fix.
> >>
> >> Previously if the user provided values ends up being invalid, PMD
> >> seems returning error.
> >> With this patch, instead of returning error PMD prefers to use
> >> default values and doesn't return error.
> >
> > It isn't behavior change.
> > It existed before, except that it is concentrated into one function.
> >
> >>
> >> I am not sure if it is correct thing to ignore (adjust) user provided
> >> values, but that can be up to the PMD as long as the behavior is
> documented.
> >
> > Adjustment is the likely thing to do because the range depends on the
> device and the user does not necessarily know it.
> > This behavior is documented here
> > https://doc.dpdk.org/guides/nics/mlx5.html#run-time-configuration
> > (Run-time configuration -> Driver options -> mprq_log_stride_num/size)
> >
>
> It is documented that adjustments will be done if any specific argument is
> not in the range of the device capability.
>
> It is not clear what will happen if the calculated value from both variables
> are
> not valid.
The driver should adjust it to a legal value.
> If it is not documented before, and previously it was returning error, now
> adjusting values to make it work looks like behavior change to me.
The driver should not return an error - the driver should adjust to a legal
value in case of illegal values by the user.
It is documented in the devargs description.
Not behavior change but a bug fix; previously, the adjustment may return an
error(which is a bug) or cause unexpected behavior in the HW(which is an old FW
bug).
Now, no error, no unexpected behavior - bug should be fixed for any FW version.
> This is more of a process question, than technical detail in the driver, so
> @Luca, @Kevin, @Christian, can you please comment? I will follow your
> suggestion.
>
>
> >>
> >> But I think it is wrong to backport the behavior change.
> >>
> >>> Signed-off-by: Michael Baum<michae...@nvidia.com>
> >>> Acked-by: Matan Azrad<ma...@nvidia.com>
> >>> ---
> >
