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.yi...@amd.com>
>>> Sent: Sunday, September 22, 2024 8:44 AM
>>> To: Hemant Agrawal <hemant.agra...@nxp.com>; dev@dpdk.org
>>> Cc: ferruh.yi...@intel.com; Vinod Pullabhatla <vinod.pullabha...@nxp.com>;
>>> Rohit Raj <rohit....@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?
