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.yi...@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?
