Re: [PATCH v2] usertools: telemetry json support pretty print

[fengchengwen <fengchengwen@huawei.com>]

Hi all,

On 2022/10/15 0:10, Morten Brørup wrote:
>> From: Bruce Richardson [mailto:bruce.richardson@intel.com]
>> Sent: Friday, 14 October 2022 17.30
>>
>> On Fri, Oct 14, 2022 at 08:01:11AM -0700, Stephen Hemminger wrote:
>>> On Fri, 14 Oct 2022 14:02:10 +0100
>>> Bruce Richardson <bruce.richardson@intel.com> wrote:
>>>
>>>> On Fri, Oct 14, 2022 at 12:44:33PM +0000, Power, Ciara wrote:
>>>>> Hi Chengwen,
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: David Marchand <david.marchand@redhat.com>
>>>>>> Sent: Friday 14 October 2022 10:50
>>>>>> To: Chengwen Feng <fengchengwen@huawei.com>
>>>>>> Cc: thomas@monjalon.net; dev@dpdk.org; Power, Ciara
>>>>>> <ciara.power@intel.com>
>>>>>> Subject: Re: [PATCH v2] usertools: telemetry json support
>> pretty print
>>>>>>
>>>>>> On Fri, Oct 14, 2022 at 5:31 AM Chengwen Feng
>> <fengchengwen@huawei.com>
>>>>>> wrote:
>>>>>>>
>>>>>>> Currently, the dpdk-telemetry.py show json in raw format,
>> which is not
>>>>>>> good for human reading.
>>>>>>>
>>>>>>> E.g. The command '/ethdev/xstats,0' will output:
>>>>>>> {"/ethdev/xstats": {"rx_good_packets": 0, "tx_good_packets":
>> 0,
>>>>>>> "rx_good_bytes": 0, "tx_good_bytes": 0, "rx_missed_errors":
>> 0,
>>>>>>> "rx_errors": 0, "tx_errors": 0, "rx_mbuf_allocation_errors":
>> 0,
>>>>>>> "rx_q0_packets": 0,...}}
>>>>>>>
>>>>>>> This patch supports json pretty print by adding extra
>> indent=4
>>>>>>> parameter, so the same command will output:
>>>>>>> {
>>>>>>>     "/ethdev/xstats": {
>>>>>>>         "rx_good_packets": 0,
>>>>>>>         "tx_good_packets": 0,
>>>>>>>         "rx_good_bytes": 0,
>>>>>>>         "tx_good_bytes": 0,
>>>>>>>         "rx_missed_errors": 0,
>>>>>>>         "rx_errors": 0,
>>>>>>>         "tx_errors": 0,
>>>>>>>         "rx_mbuf_allocation_errors": 0,
>>>>>>>         "rx_q0_packets": 0,
>>>>>>>         ...
>>>>>>>     }
>>>>>>> }
>>>>>>>
>>>>>>> Signed-off-by: Chengwen Feng <fengchengwen@huawei.com>
>>>>>>
>>>>>> It's indeed easier to read, but maybe 4 chars is too much.
>>>>>> 2 chars seem enough to me.
>>>>> [CP]
>>>>> +1 on using 2 chars
> 
> +1 to 2 spaces, following the convention of the rte_<lib>_dump() functions in DPDK.

Already fix in v3.

> 
>>>>>
>>>>>>
>>>>>> In any case I like the idea:
>>>>
>>>> I like it too, for interactive use. However, we also have some
>> hooks in the
>>>> code for when the app is being run non-interactively i.e. from a
>> script. In
>>>> that case, we probably want the indent to be unused.
>>>>
>>>> The function "handle_socket()" tracks if the output is a tty via
>> the "prompt"
>>>> variable. That could be passed through to the "read_socket()" call
>> to
>>>> optionally not-indent the output.

The v3 support indent only under interactive mode.

>>>>
>>>> /Bruce
>>>
>>> Convention in other tools is a -p flag for "pretty output"
>>
>> Since we already support detecting interactive use, I think having the
>> pretty output by default in that case is probably good.
> 
> +1 to pretty by default.
> 
>> For non-
>> interactive
>> use a -p flag might make sense, but even then I'm not sure it's hugely
>> worthwhile.
> 
> +1 to Bruce's comment about not being worthwhile. And we would need the inverse of -p. :-)

+1 for not being worthwhile.

> 
> Closely related:
> 
> If we agree that the JSON output is either for human or machine consumption, why don't we give JANSSON the JSON_COMPACT flag to save some spaces?
> 
> 
> .
>