Re: [dpdk-dev] telemetry logs

[Thomas Monjalon <thomas@monjalon.net>]

02/03/2021 12:18, Bruce Richardson:
> On Tue, Mar 02, 2021 at 12:01:12PM +0100, Thomas Monjalon wrote:
> > 02/03/2021 11:42, Bruce Richardson:
> > > On Tue, Mar 02, 2021 at 11:23:41AM +0100, Thomas Monjalon wrote:
> > > > 02/03/2021 11:14, Bruce Richardson:
> > > > > On Mon, Mar 01, 2021 at 08:22:15PM +0100, Thomas Monjalon wrote:
> > > > > > Hi,
> > > > > > Sorry if I already asked this question.
> > > > > > Would it be possible to use rte_log in rte_telemetry
> > > > > > instead of returning telemetry_log_error at init?
> > > > > > 
> > > > > It probably could be made to work by passing in the log function at init
> > > > > time. Haven't delved too much into the details, though.
> > > > 
> > > > Actually I think a better question is about the need to init telemetry
> > > > if not used. It can generate an error without a need.
> > > > Instead of the existing option --no-telemetry,
> > > > what do you think of initializing the telemetry on its first use?
> > > > This way we could remove the dependency of EAL on telemetry?
> > > > 
> > > There is no real first use - the various libraries all register their callbacks
> > > inside the init functions of the shared libraries. Having it initialized
> > > inside EAL makes things very useful, because it means that all DPDK apps
> > > automatically have telemetry available.
> > 
> > Registering libs should be always possible, yes.
> > But the init of the socket can be deffered to its use, no?
> >
> Not sure what you mean here? When would you see the socket init taking
> place if not in EAL init?

I think my request is just impossible.
My wish is that telemetry socket is initialized only when
we need it. But no, I don't know how to detect a socket query
before creating the socket...

> Of course, the other alternative to this problem is a solution you were
> previously suggesting: to move basic services such as logging to a separate
> library so that we split EAL into two parts, with the init being in the
> second higher-level part. Obviously this is a very significant amount of
> work though, so unlikely to be undertaken quickly.

I agree it would be an interesting and huge work.