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?
