telemetry logs

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?

Quoted 5 lines

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.

02/03/2021 11:14, Bruce Richardson:

Quoted 6 lines · Thomas Monjalon

Quoted 5 lines

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?

Quoted 2 lines

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?

Quoted 7 lines

02/03/2021 11:14, Bruce Richardson:

Quoted 6 lines · Thomas Monjalon

Quoted 5 lines

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?

Quoted 9 lines

Quoted 2 lines

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.

02/03/2021 11:42, Bruce Richardson:

Quoted 17 lines · Thomas Monjalon

Quoted 16 lines

02/03/2021 11:14, Bruce Richardson:

Quoted 8 lines · Thomas Monjalon

Quoted 5 lines

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?

Quoted 4 lines

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?

Quoted 23 lines

02/03/2021 11:42, Bruce Richardson:

Quoted 21 lines · Thomas Monjalon

Quoted 7 lines

02/03/2021 11:14, Bruce Richardson:

Quoted 6 lines · Thomas Monjalon

Quoted 5 lines

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?

Quoted 9 lines

Quoted 2 lines

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.

Quoted 3 lines

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.