[dpdk-dev] telemetry logs

[dpdk-dev] telemetry logs

[Thomas Monjalon]

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?

Re: [dpdk-dev] telemetry logs

[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.

Re: [dpdk-dev] telemetry logs

[Thomas Monjalon]

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?

Re: [dpdk-dev] telemetry logs

[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.

For example, end of last week I was able to put together a quick python
script to print out PPS stats for any DPDK app using the telemetry data.
Tested and developed initially using testpmd as a reference app, but ran
perfectly first time using OVS running in the background.

/Bruce

Re: [dpdk-dev] telemetry logs

[Thomas Monjalon]

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?

> For example, end of last week I was able to put together a quick python
> script to print out PPS stats for any DPDK app using the telemetry data.
> Tested and developed initially using testpmd as a reference app, but ran
> perfectly first time using OVS running in the background.

Nice

Re: [dpdk-dev] telemetry logs

[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?

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.

Re: [dpdk-dev] telemetry logs

[Thomas Monjalon]

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.