[PATCH] net/dpaa2: change threshold value

[Ferruh Yigit]

On 9/29/2023 2:50 PM, Ferruh Yigit wrote:
> On 6/9/2023 3:20 PM, Ferruh Yigit wrote:
>> On 5/15/2023 9:16 AM, Sachin Saxena (OSS) wrote:
>>> On 5/8/2023 4:11 PM, Tianli Lai wrote:
>>>> Caution: This is an external email. Please take care when clicking
>>>> links or opening attachments. When in doubt, report the message using
>>>> the 'Report this email' button
>>>>
>>>>
>>>> this threshold value can be changed with function argument nb_rx_desc.
>>>>
>>>> Signed-off-by: Tianli Lai <laitianli at tom.com>
>>>> ---
>>>>   drivers/net/dpaa2/dpaa2_ethdev.c | 2 +-
>>>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/net/dpaa2/dpaa2_ethdev.c
>>>> b/drivers/net/dpaa2/dpaa2_ethdev.c
>>>> index 679f33ae1a..ad892ded4a 100644
>>>> --- a/drivers/net/dpaa2/dpaa2_ethdev.c
>>>> +++ b/drivers/net/dpaa2/dpaa2_ethdev.c
>>>> @@ -829,7 +829,7 @@ dpaa2_dev_rx_queue_setup(struct rte_eth_dev *dev,
>>>>                                                  dpaa2_q->cgid,
>>>> &taildrop);
>>>>                  } else {
>>>>                          /*enabling per rx queue congestion control */
>>>> -                       taildrop.threshold = CONG_THRESHOLD_RX_BYTES_Q;
>>>> +                       taildrop.threshold = nb_rx_desc * 1024;
>>>>                          taildrop.units = DPNI_CONGESTION_UNIT_BYTES;
>>>>                          taildrop.oal = CONG_RX_OAL;
>>>>                          DPAA2_PMD_DEBUG("Enabling Byte based Drop on
>>>> queue= %d",
>>>> -- 
>>>> 2.27.0
>>>>
>>> Hi Tianli,
>>>
>>> The number of bytes based tail drop threshold value
>>> "CONG_THRESHOLD_RX_BYTES_Q" is an optimized value for dpaa2 platform. we
>>> concluded this value after multiple benchmark experiments in past.
>>> Although, number of frame based threshold value is "nb_rx_desc" based only.
>>> We will further review this suggestion and get back.
>>>
>>
>> Hi Sachin, What is the status of this patch?
>>
> 
> Ping
>

Hi Sachin, Hemant,

If you believe current threshold value is more optimized value, please
reject this patch, instead of letting it stuck around.

Or @Tianli if you have more arguments to prove this is better value, can
you please share them to help maintainers?