Re: [PATCH v2 14/18] net/dpaa: add Tx rate limiting DPAA PMD API

[Ferruh Yigit <ferruh.yigit@amd.com>]

On 9/22/2024 2:27 PM, Ferruh Yigit wrote:
> On 9/22/2024 5:40 AM, Hemant Agrawal wrote:
>> HI Ferruh,
>>
>>> -----Original Message-----
>>> From: Ferruh Yigit <ferruh.yigit@amd.com>
>>> Sent: Sunday, September 22, 2024 8:44 AM
>>> To: Hemant Agrawal <hemant.agrawal@nxp.com>; dev@dpdk.org
>>> Cc: ferruh.yigit@intel.com; Vinod Pullabhatla <vinod.pullabhatla@nxp.com>;
>>> Rohit Raj <rohit.raj@nxp.com>
>>> Subject: Re: [PATCH v2 14/18] net/dpaa: add Tx rate limiting DPAA PMD API
>>> Importance: High
>>>
>>> On 8/23/2024 8:32 AM, Hemant Agrawal wrote:
>>>> diff --git a/drivers/net/dpaa/version.map
>>>> b/drivers/net/dpaa/version.map index 3fdb63caf3..24a28ce649 100644
>>>> --- a/drivers/net/dpaa/version.map
>>>> +++ b/drivers/net/dpaa/version.map
>>>> @@ -6,6 +6,13 @@ DPDK_25 {
>>>>  	local: *;
>>>>  };
>>>>
>>>> +EXPERIMENTAL {
>>>> +	global:
>>>> +
>>>> +	# added in 24.11
>>>> +	rte_pmd_dpaa_port_set_rate_limit;
>>>> +};
>>>> +
>>>>  INTERNAL {
>>>>  	global:
>>>>
>>>
>>> PMD specific API needs to be justified, can't we use TM framework for this,
>>> does TM needs to be improved for this support?
>>>
>>> What do you think to send the rest of the set without this patch, so they can
>>> progress, and this one can be discussed separately (assuming there is no
>>> dependency).
>>
>> [Hemant] I think, I replied to your earlier concerns. 
>>
>> We are yet to implement TM framework for DPAA1.  But that involves more of egress QoS.
>>
>> This one is additional capability to limit the ingress port. Kind of policing in Rx side.
>>
>> However, if you still disagree. Please apply the series without this patch.
>>
> 
> Let's detect what is missing in ethdev layer for it, and what is the
> required effort to cover it in ethdev, first. Based on findings, we can
> continue with PMD API as last resort.
> 
> I will continue with patch series without this path.
>

Hi Hemant,

I removed the commit 14/18 from set, but it impacts other patches, I can
fix the build but can't verify the functionality, probably better if you
send a new version without patch 14/18.

Btw, while resolving conflict I recognized that patch 15/18 renames
'fman_offline_internal' -> 'fman_offline', and next patch (16/18),
renames it back to 'fman_offline_internal', this creates lots of noise
in both patches, can this be prevented, I will comment on the patch?