[dpdk-dev] No telemetry legacy support print

[dpdk-dev] No telemetry legacy support print

[Jerin Kollanukkaran]

"No telemetry legacy support " prints pops up on all the default dpdk applications now.
Is it worth to print? Since it using direct 'printf', we cannot even disable through dynamic logging.
Is possible to remove that print at least, if non legacy telemetry init is successful. 
Thoughts?

Re: [dpdk-dev] No telemetry legacy support print

[David Marchand]

On Fri, May 22, 2020 at 9:15 AM Jerin Kollanukkaran <jerinj@marvell.com> wrote:
>
> "No telemetry legacy support " prints pops up on all the default dpdk applications now.
> Is it worth to print? Since it using direct 'printf', we cannot even disable through dynamic logging.
> Is possible to remove that print at least, if non legacy telemetry init is successful.
> Thoughts?

This init function is odd as it calls printf in error and warning
cases and sets an error string when it succeeds.
Let's remove the two printf in this init function.

If we really care about the warning message, we have to initialise
*err_str to NULL (+ this must be described in the function prototype).
In EAL init, we can then add a rte_eal_init_alert with the error
string when telemetry init fails and maybe a warning message if
err_str != NULL.


-- 
David Marchand

Re: [dpdk-dev] No telemetry legacy support print

[Thomas Monjalon]

22/05/2020 09:47, David Marchand:
> On Fri, May 22, 2020 at 9:15 AM Jerin Kollanukkaran <jerinj@marvell.com> wrote:
> >
> > "No telemetry legacy support " prints pops up on all the default dpdk applications now.
> > Is it worth to print? Since it using direct 'printf', we cannot even disable through dynamic logging.
> > Is possible to remove that print at least, if non legacy telemetry init is successful.
> > Thoughts?
> 
> This init function is odd as it calls printf in error and warning
> cases and sets an error string when it succeeds.
> Let's remove the two printf in this init function.
> 
> If we really care about the warning message, we have to initialise
> *err_str to NULL (+ this must be described in the function prototype).
> In EAL init, we can then add a rte_eal_init_alert with the error
> string when telemetry init fails and maybe a warning message if
> err_str != NULL.

There are 5 printf in telemetry.
The definitive fix should be to split EAL:
- 1 low-level layer offering arch and OS support, including early logs.
- 1 high-level layer including configuration parsing and rte_eal_init().

Re: [dpdk-dev] No telemetry legacy support print

[Power, Ciara]

>-----Original Message-----
>From: David Marchand <david.marchand@redhat.com>
>Sent: Friday 22 May 2020 08:47
>To: Jerin Kollanukkaran <jerinj@marvell.com>; Richardson, Bruce
><bruce.richardson@intel.com>; Power, Ciara <ciara.power@intel.com>
>Cc: Wiles, Keith <keith.wiles@intel.com>; Thomas Monjalon
><thomas@monjalon.net>; dpdk-dev <dev@dpdk.org>
>Subject: Re: No telemetry legacy support print
>
>On Fri, May 22, 2020 at 9:15 AM Jerin Kollanukkaran <jerinj@marvell.com>
>wrote:
>>
>> "No telemetry legacy support " prints pops up on all the default dpdk
>applications now.
>> Is it worth to print? Since it using direct 'printf', we cannot even disable
>through dynamic logging.
>> Is possible to remove that print at least, if non legacy telemetry init is
>successful.
>> Thoughts?
>
>This init function is odd as it calls printf in error and warning cases and sets an
>error string when it succeeds.
>Let's remove the two printf in this init function.
>
>If we really care about the warning message, we have to initialise *err_str to
>NULL (+ this must be described in the function prototype).
>In EAL init, we can then add a rte_eal_init_alert with the error string when
>telemetry init fails and maybe a warning message if err_str != NULL.
>
>
>--
>David Marchand


I agree with this solution, I can work on getting a patch done to fix this.
Thanks!

- Ciara