Re: [PATCH] drivers: remove compile-time option for IEEE 1588

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

On 11/3/2023 12:08 AM, Ferruh Yigit wrote:
> On 11/2/2023 10:17 PM, Thomas Monjalon wrote:
>> 02/11/2023 22:21, Ajit Khaparde:
>>> On Thu, Nov 2, 2023 at 2:13 PM Ferruh Yigit <ferruh.yigit@amd.com> wrote:
>>>> On 6/25/2023 4:45 PM, Thomas Monjalon wrote:
>>>>> 23/06/2023 16:00, Ferruh Yigit:
>>>>>> On 2/3/2023 1:28 PM, Thomas Monjalon wrote:
>>>>>>> The option RTE_LIBRTE_IEEE1588 has no effect on any library
>>>>>>> unlike its name.
>>>>>>>
>>>>>>> Also we are suppose to enable/disable features dynamically,
>>>>>>> not at compilation time.
>>>>>>>
>>>>>>> And the best is that this macro is neither documented,
>>>>>>> nor in rte_config.h.
>>>>>>>
>>>>>>> It looks to be a mistake keeping this flag, so it is removed,
>>>>>>> meaning always enabled.
>>>>>>> PS: it is disabling vector paths of some drivers.
>>>>>>>
>>>>>>
>>>>>> PTP (IEEE1588) processing brings additional overhead to datapath.
>>>>>>
>>>>>> Agree that it is not good to have undocumented compile macro, but just
>>>>>> removing it may cause performance degradation.
>>>>>>
>>>>>> It may be possible to have separate burst function that supports PTP and
>>>>>> driver configures it when application explicitly request it with a new
>>>>>> offload flag (although it is not exactly an offload), what do you think?
>>>>>
>>>>> The best is to enable dynamically with different functions.
>>>>
>>>> There was no comment from driver maintainers.
>>
>> If I made a baby when sending this patch, it would be a birth today.
>> Isn't it enough time to warn maintainers?
>>
>>>> Perhaps better option is plan flag removal and execute it, like to
>>>> remove the flag in 24.11 LTS, this gives enough time for drivers to update.
>>
>> You want to give time for one more baby?
>>
>>>> If this sounds good, I can send a deprecation notice to record this plan.
>>> +1
>>
>> Which plan? 2 babies?
>>
>>
> 
> :) remove compile flag in 24.11 LTS.
> 
> But we may end up in same situation in 24.11, some drivers not being
> ready, so we should merge this patch very early in the 24.11 to give
> time to drivers to fix if they were not ready at that time.
> 
> Other option is merge this patch in 24.07, so that vendors which were
> not ready can plan a fix for 24.11? Although enforcing an update by
> breaking the driver is not best planning, it may be an efficient one.
>

Hi Thomas and et al. ,

Is is good time to merge this patch, there is enough time to fix
potential issues in this release, what do you think?