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

[Thomas Monjalon <thomas@monjalon.net>]

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?